Glossary
What Is IDOR (Insecure Direct Object Reference)?
IDOR (Insecure Direct Object Reference) is a vulnerability where the application exposes references to internal objects (database IDs, filenames) without verifying the caller is authorized to access them. Sequential IDs (/users/123) make exploitation trivial — an attacker increments the ID and reads other users' data. CWE-639 is the canonical identifier.
Why IDOR is hard for scanners but easy for humans
A vulnerability scanner doesn't know what data belongs to which user. It sees GET /api/users/123 returning a 200 and has no way to verify the caller should have access. A human pentester (or SQUR's validator running two parallel auth sessions) can construct the cross-account request and confirm whether the response leaks data. This is why SQUR's benchmark scored 100% on IDOR-class findings — the validator does the cross-user comparison automatically.
IDOR variants
- Sequential ID —
/users/123incrementable - UUID — harder to guess, but if leaked (Referer headers, logs, screenshots), same exploit shape
- Username-based —
/profiles/john.doe— enumerable - Filename / path —
/files/Report-Q4-2026.pdf— guessable patterns - Encrypted / signed IDs — if the signing is broken (predictable IV, weak HMAC), the IDOR re-emerges
How IDOR differs from BOLA
The OWASP API Top-10 prefers BOLA (Broken Object-Level Authorization) for the same root-cause class in API contexts. In practice they're synonyms: BOLA in OWASP API Top-10 framing; IDOR in older web-app vocabulary. Both describe missing authorization at the object level. Some authors distinguish: IDOR = sequential / guessable IDs; BOLA = any object-level authz miss regardless of ID predictability.
Remediation pattern
The fix is the same as BOLA: explicit authorization check per request. if (resource.owner_id != current_user.id) return 403. ABAC / RBAC libraries that fail closed. Opaque resource IDs (UUIDs over sequential) are defence in depth — not a substitute for the authz check.
Frequently asked questions
Aren't UUIDs enough?
No. UUIDs prevent guessing but don't prevent leaking. If a UUID appears in a Referer header, log line, screenshot, or shared URL, the attacker has it — and there's still no authz check. UUIDs are useful belt + braces; the authz check is the load-bearing fix.
How widespread is IDOR?
Extremely. SQUR finds IDOR in roughly 30% of B2B SaaS APIs we scan. It compounds with multi-tenancy: any cross-tenant IDOR is typically critical (CVSS 8-9) because tenant data is the asset.