IDORSSRFAUTH BYPASSJWT FORGERYRACE CONDITIONXXEBROKEN OBJECT-LEVEL AUTHPRIVILEGE ESCALATIONMASS ASSIGNMENTGRAPHQL INTROSPECTION ABUSEIDORSSRFAUTH BYPASSJWT FORGERYRACE CONDITIONXXEBROKEN OBJECT-LEVEL AUTHPRIVILEGE ESCALATIONMASS ASSIGNMENTGRAPHQL INTROSPECTION ABUSE
Impactr Logoimpactr
FeaturesHow it worksEvidencePricingLearnCompare
  1. Home
  2. Learn
  3. Insecure Direct Object Reference (IDOR)
Access ControlHigh

Insecure Direct Object Reference (IDOR)

Also known as: IDOR · Broken Object Level Authorization · BOLA

An Insecure Direct Object Reference (IDOR) - known in API contexts as Broken Object Level Authorization (BOLA) - happens when an application uses user-supplied input to access objects directly but does not check that the requester owns or may access that object. Because the identifiers are often sequential or guessable, an attacker can substitute another user's ID and read or modify data that is not theirs.

CWE
CWE-639CWE-284
OWASP
A01:2021API1:2023

How it works

  1. 1The application references an object by an identifier in the URL, body, or header (e.g. /accounts/48213).
  2. 2Authorization is enforced at the route (are you logged in?) but not at the object (is this object yours?).
  3. 3The attacker changes the identifier to one belonging to another user or tenant.
  4. 4The server returns or modifies the other object, leaking or tampering with data across the authorization boundary.

Example

GET /api/v2/invoices/48213 HTTP/2
Host: target.example
Authorization: Bearer <token for account 91077>

# 200 OK returns invoice 48213, owned by a different account
A token scoped to one account reads another account's object.

Impact

IDOR/BOLA leads to cross-tenant data exposure, account takeover, and mass data extraction by enumeration. It is consistently among the most impactful and most missed API vulnerabilities.

Remediation

  • Enforce object-level authorization on every request: verify the current principal owns or may access the specific object.
  • Prefer unpredictable identifiers (UUIDs) - but never rely on them as the only control.
  • Centralize access-control checks in a policy layer rather than scattering them per handler.
  • Add automated tests that replay one user's token against another user's objects.

Detection & testing

Test every object-referencing endpoint with two accounts and confirm cross-access is rejected. Watch for enumeration patterns and 200 responses to objects a principal should not own.

Impactr tests for Insecure Direct Object Reference (IDOR) the way an attacker would - investigating, chaining it with related flaws, and proving impact with a reproducible exploit before it reaches your report.

Test my app for IDOR

Tools

ImpactrBurp Suite (Autorize)Caido

Frequently asked questions

Is IDOR the same as BOLA?

Effectively yes. BOLA (Broken Object Level Authorization) is the term OWASP uses for IDOR in the API Security Top 10. Both describe missing per-object authorization checks.

Do UUIDs prevent IDOR?

No. Unpredictable IDs make enumeration harder but are not an access control. If the server still doesn't verify ownership, an attacker who obtains a valid ID can access the object.

Related concepts

Broken Access ControlCross-Site Request Forgery (CSRF)JWT Attacks
← All vulnerabilities
Impactr Logoimpactr

Built by hackers, for the code you ship. Autonomous AI penetration testing for modern web apps and APIs.

© 2026 Impactr

Product

FeaturesCoverageUse casesEvidencePricingWaitlist

Resources

VulnerabilitiesGuidesComparisonsGlossaryCWE databaseBy industryBy languageHTTP status codesSecurity headers

Company

ContactTwitterLinkedInGitHub