IDOR vs BOLA

Same vulnerability, different names. Here's why both exist and when to use which term.

The short answer

They're the same vulnerability under two names. IDOR is the older term from the web application testing tradition; BOLA is what the OWASP API Security Top Ten calls it. If someone tells you they're different bugs, the distinction they're reaching for is usually about context — APIs versus web pages — rather than about mechanism.

Why two names exist, and when the difference matters

The terms come from different lineages. "Insecure Direct Object Reference" entered general use through the OWASP Top Ten in the 2000s, when the surface was server-rendered applications and the object reference was typically a query-string parameter. "Broken Object Level Authorization" was coined for the 2019 API Security Top Ten, where it sits at number one. The rename was deliberate: "insecure direct object reference" describes the symptom (a reference the user can manipulate) while "broken object level authorization" names the actual defect (a missing check). The second framing is more useful, because it points at the fix.

Use BOLA when you're writing about APIs, particularly in a report to a team that works from the API Security Top Ten — it maps to a category they already track. Use IDOR in bug bounty contexts, where it remains the dominant vocabulary and is what triagers search for. Most platforms accept either, and the sensible move in a report is to lead with one and mention the other once, so it's findable under both.

Where the distinction does carry weight is severity modelling. APIs tend to expose object references more directly and in greater volume than server-rendered applications did — every resource is an addressable identifier, and there's no UI layer incidentally limiting what most users ever request. That's a real difference in exposure, and it's why the API list elevated it to first place. It's a difference in surface area, not in the bug.

Finding them, whatever you call them

The method doesn't change with the terminology. Hold two authenticated sessions in different accounts or tenants. Exercise the application fully as account A, capturing traffic. Replay those requests with account B's credentials and look at what succeeds. Burp's Autorize extension automates exactly this loop and is the single most useful tool for the class.

The subtleties are worth knowing. Sequential integers are the obvious case, but UUIDs only help if they're both unguessable and still checked — plenty of applications treat an opaque identifier as authorization in itself, which fails the moment an identifier leaks through a share link, an export, or a referrer header. Check the non-obvious verbs: an endpoint that correctly rejects a foreign ID on read may accept it on update, on delete, or on a "duplicate this record" action nobody classified as a read. Check asynchronous paths, where a background worker fetches the object and never sees the requesting user: export jobs, PDF generation, webhooks, notification emails.

Mass assignment sits next door and is frequently reported as IDOR. If you can add "account_id": 7 or "role": "admin" to a request body and the framework binds it, the object reference was never the problem — that's a separate finding with a separate fix.

Fixing it properly

Adding a check to the handler fixes one endpoint. The defect is that the check was omissible, and the next endpoint will omit it too. The durable fix is to make the ownership constraint structural: scope queries at the data access layer so a record outside the caller's tenant cannot be returned, and deny by default. Unpredictable identifiers are worth using as defense in depth, and are not a substitute for the check. More at IDOR, API Security and Authorization.