What Is IDOR (Broken Object Level Authorization)?
IDOR/BOLA is a top web and API risk: accessing another user’s data by changing an ID. How it works, why scanners miss it, and how to prevent it.
IDOR (Insecure Direct Object Reference) — known as BOLA (Broken Object Level Authorization) in APIs — is the flaw where an app uses an identifier from the request to fetch an object without checking the user is allowed to see it. Change the ID, get someone else’s data. It is the most common entry in the OWASP API Security Top 10 and a leading cause of real breaches.
How it works (a concrete example)
An app loads an invoice with a request like:
GET /api/invoices/1042
If the server returns invoice 1042 without verifying it belongs to the logged-in user’s organization, an attacker simply changes 1042 to 1043 and reads another customer’s invoice. No special tools required — just an authenticated session and a different number.
Why scanners miss it
An automated scanner sees a 200 response and moves on. It has no idea that record 1043 belongs to a different tenant — only a human (or a test) that understands your authorization model can recognize the problem. That is why a vulnerability scan can’t replace a penetration test for access-control bugs.
How to prevent IDOR / BOLA
- Authorize every object access — confirm the user owns or may access the specific record, server-side, on every request
- Centralize the check — use a single authorization layer rather than per-endpoint ad-hoc logic
- Prefer non-guessable IDs — UUIDs reduce trivial enumeration (but are not a substitute for authorization)
- Test with multiple accounts — add automated tests that attempt cross-account access and fail the build if they succeed
AssuranceOps explicitly tests object-level authorization across roles and tenants in Web App and API Security Assurance.
Ready to test your own systems? Request a security assessment or explore Security Assurance packages.
Frequently asked questions
- What is IDOR?
- IDOR (Insecure Direct Object Reference) is an access-control flaw where an application uses a user-supplied identifier to fetch an object without verifying the user is authorized to access it. Changing the ID in a request returns someone else’s data. In API contexts it is called BOLA (Broken Object Level Authorization), the top risk in the OWASP API Security Top 10.
- Why do vulnerability scanners miss IDOR?
- Scanners do not understand which user should be allowed to see which object, so they cannot tell that returning record #1042 to the wrong user is a problem. Detecting IDOR/BOLA requires testing with multiple accounts and understanding the application’s authorization model — which is human-led penetration testing.
- How do you prevent IDOR/BOLA?
- Enforce object-level authorization on every request: verify the authenticated user owns or may access the specific object before returning it. Prefer non-guessable identifiers, centralize authorization checks, and add automated tests that attempt cross-account access.
Prove your systems are ready.
Human-validated security assurance with an audit-ready evidence pack.
Request an assessmentRelated reading
- Penetration Test vs Vulnerability Scan: What’s the Difference?
Scans are automated and cheap; pen tests are human-validated and prove real risk. When to use each — and what auditors and customers actually expect.
- How Much Does a Penetration Test Cost?
What a pen test actually costs in 2026, the factors that move the price, and how to scope an assessment so you don’t overpay or under-test.
- Securing LLM and RAG Applications
LLM and RAG apps introduce risks traditional pen tests miss. The top AI-specific threats and a concrete checklist to test and mitigate them.