IDOR: The Bug That Keeps Slipping Through

An endpoint accepts an object identifier from the user — an integer, UUID, hash — and returns or modifies the matching record without checking that the authenticated user is authorized for it. The vulnerability is the missing check, not the predictable ID. Even UUIDs and signed IDs are vulnerable if the authorization check is missing downstream.

We authenticate as two low-privilege users in separate tenants. Then we walk every endpoint that takes an object identifier, swap user A's ID with user B's, and replay. A 200 response is a finding. A 404 is suspicious (404 vs 403 leaks existence). We do this systematically — for every CRUD operation, every nested resource, every export endpoint.

GET /api/invoices/4192          → user A's invoice (legitimate)
GET /api/invoices/4193          → user B's invoice (should be 403)
PATCH /api/invoices/4193        → modifying B's data from A's session
GET /api/exports/run/4193       → background export of B's data

• Bulk operations — POST /api/items/bulk-delete with an array of IDs; the per-item check is missing
• Filename in storage URLs — /files/{user_id}/{filename} served by a CDN with no authz layer
• Webhooks and exports — async jobs that re-fetch data and skip the original session check
• GraphQL nested resolvers — parent is authorized, child resolver is not

Centralize authorization in a single layer. Make the authorized entity (the current user) the implicit owner of every query — repositories should take userId as a mandatory parameter, never accept a raw object ID without one. For deeper coverage, our code review service maps every endpoint against an authz matrix.