Access Control
Broken Access Control
0 / 5 solved
Test real application routes for missing object, role, and tenant authorization checks.
Quick reference
Broken Access Control cheat sheet
Map who you are, which object or function you are requesting, and what should happen if you change that relationship.
Where to look
- URLs and API bodies containing userId, accountId, orderId, invoiceId, projectId, fileId, UUIDs, hashes, or slugs.
- Hidden admin links in JavaScript bundles, network requests, robots.txt, API documentation, or predictable route names.
- Download endpoints, profile pages, edit/delete actions, organization/tenant resources, and background API calls.
Simple checks
- Capture one legitimate request, change only the object identifier, and resend it.
- Use two test accounts when possible: copy an object ID from account B and request it while logged in as account A.
- Try privileged endpoints directly even when the UI hides the button.
GET /api/profile/1001 → try /api/profile/1002GET /files/7dcaa8ea-... → reuse a UUID leaked elsewhereGET /profile/fba9d881... → check whether the hash is only obfuscating a predictable IDRealistic approach
- Do not assume UUIDs or hashes are authorization. First ask where identifiers can leak: directories, logs, links, exports, notifications, or other APIs.
- Test both read and write actions. A page may block viewing but still allow update/delete through a separate endpoint.
- For multi-tenant apps, change organization/project/file identifiers and verify the server checks tenant ownership on every request.
- A secure response should deny the request server-side; hiding data in the frontend is not enough.