IDOR and Broken Access Control

• It is routinely the number-one-ranked web risk because the flaw lives in business logic, invisible to scanners.
• The blast radius is huge: IDOR across an API commonly exposes every customer record with a single sequence number.
• Learning to test as 'user A vs user B' is the single most transferable pentest skill.

The labels are sequential, the handles are unlocked, and nobody checks who walks in.

• The app trusts the user-supplied object ID (invoice/1234, uid=42) and authenticates the session but never authorizes the object.
• Horizontal: user A reads user B's same-type object. Vertical: a normal user calls an admin endpoint directly.
• Scanners know nothing about your business objects, so discovery requires two accounts and manual inference.
• The fix is a middleware check on every object fetch: does THIS principal have rights over THIS resource?

• A SaaS added an object-access policy layer at the API gateway; invoice/1234 for user B now 403s before the handler runs.
• A fintech's admin endpoints moved behind a separate middleware that checks 'is_admin' on every route, not just the menu.
• A pentest found an IDOR in a PDF-export endpoint; the fix was a query scoping by the owner column instead of a raw id.

• Authorize every object access with an explicit owner check; never scope queries by id alone.
• Use non-enumerable identifiers (UUIDs) AND enforce authorization — you need both layers.
• Centralize the authorization check (policy/permission service) so every route hits the same gate.
• Return the same 403/404 for both 'no such record' and 'no access' to stop enumeration signaling.

• Protecting the list page but forgetting the detail/export/download endpoints that show each single record.
• Relying on 'the UI hides the button' as authorization while the API remains unguarded.
• Authorizing at the controller for one path and skipping the identical logic in a bulk or admin endpoint.
• Assume-only: never running the two-account differential test that would have found the bug.

• The two-account test: log in as A, capture the request/response; as B, replay and diff the result.
• Swap a sequence id for a UUID and check whether the handler still resolves it — predictors rarely work with UUIDs.
• Watch HTTP status codes: a 200 where a 403 belongs is the entire report in one number.

• Differential testing must use accounts and data you own in a lab; crossing into other users' records is out of bounds.
• If you find an access-control gap in a real product, report through the ownership line — never demonstrate on live records.
• Treat the access-control audit as part of every release: it is the cheapest regression to skip and the most damaging to miss.