playbookSecurity Playbooks~1 min readUpdated Apr 23, 2026

Exploit IDOR

Goal

Determine whether object identifiers can be manipulated to access another user's data or actions.

Assumptions

the app exposes object-specific routes, IDs, or references
authorization might be weaker than authentication
the server may trust client-supplied identifiers too much

Prerequisites

authenticated test accounts with different privilege scopes
ability to capture and replay requests
understanding of object locations in the app

Recon steps

Map endpoints that expose object IDs in paths, query params, forms, or JSON.
Compare requests from two different users.
Look for predictable IDs, UUID reuse, sequential records, or leaked references.

Exploit / test steps

Capture a request that accesses one object.
Change only the object identifier.
Replay the request with the same auth context.
Try both read and write operations.
Repeat across hidden endpoints, exports, downloads, and mobile/API routes.

Validation clues

another user's object is returned
writes succeed against another user's resource
response metadata changes without an authorization error
timing or status changes indicate object existence

Mitigation

enforce authorization on every object access server-side
use indirect references only as a helper, not a replacement
avoid relying on UI visibility for protection
log authorization failures and suspicious object access patterns

Logging / detection

repeated access attempts across adjacent IDs
many 403/404 combinations across the same route family
auth context accessing objects outside expected ownership scope

References

Testing / Lab: PortSwigger IDOR page — https://portswigger.net/web-security/access-control/idor
Testing / Lab: PortSwigger access control topic — https://portswigger.net/web-security/access-control
Foundational: OWASP WSTG authorization testing — https://owasp.org/www-project-web-security-testing-guide/latest/