Can test user A read test user B’s record?
A small, repeatable access-control smoke test catches one common class of release mistake: a server trusts an object ID supplied by the browser without checking that the signed-in user owns or may access that object.
Set up the test
- Create two test usersSign in as user B and create a harmless record with a distinctive test value, such as `ACCESS-CHECK-B-001`.
- Find the normal read requestUsing your browser’s developer tools or an API client you control, identify how user B’s screen fetches that record. Note the route and object ID; don’t copy cookies or bearer tokens into notes.
- Sign in as user AUse a separate session or private browser profile so the request is authenticated only as A.
- Repeat the read as ARequest B’s record through the same route, replacing only the test record ID. Keep the request within your staging/test system and avoid changing or deleting data.
- Check the complete responseLook at the HTTP status and body. The app should deny access or return a response that reveals no protected record fields. A hidden UI element is not enough.
- Repeat on other object actionsIf the app has update, delete, download, or export routes, create separate disposable test data and verify each relevant action is also authorized server-side.
- Keep the regression testTurn the case into an automated test using the project’s existing test framework. Run it in CI so a later change does not silently remove the check.
Record evidence clearly
Route and action: [for example, GET /api/records/{id}]
Test identities: user A / user B (synthetic accounts)
Expected: user A cannot read user B’s record
Observed: [status and whether protected fields appeared]
Follow-up owner: [name or role]
This is one narrow smoke test, not a complete authorization review. Also check tenant boundaries, nested resources, bulk endpoints, exports, admin actions, role changes, and direct file URLs where they exist. OWASP’s current Top 10 lists Broken Access Control first, and its Authorization Cheat Sheet recommends validating permissions on every request.