Insecure Direct Object Reference (IDOR) testing, proven
Insecure Direct Object Reference (IDOR) (IDOR) — what it is, why a signature scanner structurally cannot find it, and how SuperPentest proves it with a controlled test, clean-session reproduction and hash-chained evidence mapped to A01: Broken Access Control.
IDOR is a vulnerability class a signature scanner structurally cannot find — here is what it is, why that is, and how SuperPentest proves it on your app.
What IDOR is
IDOR is when an application exposes a reference to an object — an order ID, a document key, a user ID — and fails to check that the caller is actually allowed to access that object. Change the number, get someone else’s data. It is the archetype of broken access control and consistently one of the most common real-world breaches.
What it looks like
An invoice link reads /api/invoices/10432. Change it to 10431 and the app returns another tenant's invoice — same valid session, no error. Walking the IDs in order dumps every customer's billing data.
Why a scanner misses it
This is a class a signature scanner structurally cannot reach. A scanner has no model of who should be allowed to see what, so it cannot tell a legitimate 200 from a cross-tenant leak. IDOR only surfaces when the same request is replayed as a different identity and the responses are compared against the rules the app is meant to enforce.
How SuperPentest proves it
SuperPentest treats IDOR the way an attacker does, in four steps: it understands the business rule the feature is meant to enforce, runs a controlled test against it, then reproduces any candidate from a clean session — a fresh login with no leftover state — and finally records the impact with hash-chained request/response evidence mapped to the control it breaks. Nothing is reported as a finding until that clean-session reproduction succeeds; a candidate is not a finding.
- Understand — map the feature and the rule it should enforce.
- Controlled test — exercise the class safely, within the authorized scope.
- Clean-session reproduction — break in again from a fresh session to rule out flukes and stale state.
- Impact + evidence — hash-chained request/response, mapped to A01: Broken Access Control and your compliance controls.
Access-control testing by replay → · IDOR glossary →
Where it fits in coverage
Insecure Direct Object Reference (IDOR) is one of the 35 vulnerability classes the engine tests every run, driven through 40+ specialist tools orchestrating 13 industry-standard open-source scanners. See the full coverage map or the 35 classes explained.
Related vulnerability classes
CSRF testing · WebSocket testing · SQLi testing · XSS testing.
FAQ
Can a scanner find IDOR?
No — not reliably. Insecure Direct Object Reference (IDOR) depends on context a signature scanner has no model of, so it is missed by construction. It takes an investigation that reproduces the issue to prove it.
How do I know a reported IDOR finding is real?
Every finding is reproduced from a clean session with hash-chained request/response evidence you can replay. If a run cannot complete the checks, it is stamped degraded coverage rather than passed as clean. See how findings are verified →
Test your app for IDOR. Book a demo or request an evaluation account. See the sample report.