BREAKYOURAPP · TESTING NOTES
API Access Control Testing: Two Accounts, One Private Resource
Published · About BreakYourApp
Authorization testing asks whether a particular session can access data it should not see. The most useful starting point is a known private resource, two dedicated test accounts and a verified owner baseline—not guessed endpoints or a status code alone.
Define the resource and sharing policy
Choose one read-only JSON endpoint on the same origin as your staging app. The endpoint should return a synthetic value that is unique to account A’s private record. Confirm that account B and an anonymous visitor are not intended recipients.
A public project or a record intentionally shared with B is not an isolation defect. Document the expected policy first. Use a unique marker in a JSON string value, rather than a generic word that could also appear in an error message. BreakYourApp checks that declared marker; it does not infer confidentiality for every field.
Prove the owner baseline
Start with a new browser context, sign in as A and visit the private UI resource. Verify the marker appears there and in the configured API response. This links the test to a record that actually exists and is accessible to its owner.
If A cannot establish the baseline, stop the comparison and report blocked. A missing or deleted record would otherwise create an apparent access-control pass for everyone, while demonstrating no policy at all.
Prove the second account is authenticated
Use a separate browser context for B with its own cookies. After login, visit B’s authenticated homepage and verify B’s own marker before requesting A’s resource. Never reuse A’s session for the comparison.
If B’s login fails, denied access cannot demonstrate cross-user isolation. Mark B’s check blocked. You can still evaluate a separately completed anonymous check, but its success does not stand in for a valid authenticated B test.
Read the body as well as the status
A 403 response can leak data in an error object or nested string value. Conversely, a valid JSON response containing no declared marker verifies only the absence of that marker from that response.
An HTTP 500, malformed JSON, unsupported content type, out-of-scope redirect or incomplete observation cannot establish privacy. The scanner records a reason and blocks that check rather than turning uncertainty into a pass.
| Test condition | Expected observation | Evidence or interpretation |
|---|---|---|
| Owner 200 with marker | Baseline established | Proceed to isolated sessions |
| B or anonymous JSON with marker | Failed check | Review policy and exposure |
| 403 JSON with marker | Failed check | Denied status still exposes the value |
| Valid allowed response without marker | Passed marker check | Other fields are not verified |
| Login failure or incomplete JSON | Blocked | No complete evidence for a verdict |
What the report proves
BreakYourApp records the declared endpoint, session scope, verdict and reason. Raw API responses and the private marker are not stored in these access-check results. Review broader data handling separately, because screenshots from other scan activity may contain application content.
This is a configured GET resource check. It does not enumerate object IDs, test every role, attempt privilege-changing writes or certify the application as secure. For a real isolation failure, review the server’s authorization enforcement with your engineering team, fix it, and rerun the same controlled comparison.