IDOR Vulnerability: How to Find and Exploit It (2026)

What Is an IDOR Vulnerability?

IDOR stands for Insecure Direct Object Reference. It is an access control flaw where an application exposes a reference to an internal object (a database row, a file, a document) and lets whoever is logged in supply that reference without verifying they own the object. Change the reference, receive a different object.

Split the name in half and it explains itself. A direct object reference is normal and unavoidable: every application needs some way to say "give me record 4417". The insecure part is the missing authorization check. Your app is not broken because 4417 appears in the URL. It is broken because the server never asked whether the person requesting 4417 has any business seeing it.

Underneath, this maps to CWE-639: Authorization Bypass Through User-Controlled Key, which MITRE rates as having a high likelihood of exploitation. MITRE lists "Insecure Direct Object Reference (IDOR)" and "Broken Object Level Authorization (BOLA)" as alternate names for the same weakness, so if you meet all three terms in a report, they describe the same failure.

The short version every beginner should memorize: authentication asks who you are, authorization asks what you are allowed to touch. An IDOR is an app that nailed the first question and skipped the second.

How an IDOR Attack Works, Step by Step

How does an IDOR attack work? You log in as a legitimate user, find a request that carries an identifier you control, change that identifier to one belonging to someone else, and send it. If the server returns their data instead of an error, the access control is broken. There is no bypass of the login, because you never needed one.

Here is the exchange in full. You are logged into a support portal as a normal customer and you open one of your own tickets:

GET /api/tickets/4417 HTTP/1.1
Host: helpdesk.acme.example
Cookie: session=a9f31c0b7e2d...

HTTP/1.1 200 OK
{"id":4417,"owner":"[email protected]","subject":"Refund request","body":"..."}

You change one character and send it again:

GET /api/tickets/4418 HTTP/1.1
Host: helpdesk.acme.example
Cookie: session=a9f31c0b7e2d...

HTTP/1.1 200 OK
{"id":4418,"owner":"[email protected]","subject":"Card declined","body":"..."}

The server checked your cookie, decided you were logged in, and then read ticket 4418 out of the database because you asked for it. Nothing in that code path ever compared owner to your session. That gap is the whole vulnerability.

1. Get an authenticated session. Register or log in as an ordinary user. You are not attacking the login, you are abusing what a normal account can already reach.
2. Find a reference you control. Watch the traffic and note every ID, username, filename, and reference number the browser sends. Each one is a candidate.
3. Change it and read the response carefully. A 200 with someone else's data is a confirmed IDOR. A 403 means that endpoint checks. A 404 often means the check exists and the app is hiding whether the record does, which is good practice.
4. Prove impact, then stop. One record belonging to a second account you control is enough for the report. Pulling ten thousand records is a data breach with your name on it.

Read, Write, and Blind: The Three Shapes of an IDOR

Most articles stop at "you can read other people's data". Bug hunters ask a second question: can you also write? That is the difference between information disclosure and account takeover.

Read IDOR (disclosure)

A GET request returns an object you do not own. Invoices, medical records, private messages, uploaded files, support tickets. This is the most common form and the easiest to prove. Severity depends entirely on what the object contains: another user's public display name is noise, their scanned passport is a critical.

Write IDOR (tampering and takeover)

A POST, PUT, or PATCH modifies an object you do not own. The classic is a profile update endpoint that accepts a user_id in the body: change it to someone else's, set their email address to yours, then run a password reset. That chain turns a "medium" into full account takeover, which is why you should always test the write path even when the read path is properly locked down.

Blind IDOR (no data comes back)

Some endpoints return an empty 200 or a bare success message no matter whose object you touched. That does not mean it failed. If POST /api/invites/4418/resend answers {"status":"sent"}, check whether an email actually landed in the second account's inbox. In practice this is where beginners give up too early, because the response body looks boring and the side effect happens somewhere they were not watching.

Where IDORs Hide in Modern Applications

Everyone checks the URL bar, which is why URL-bar IDORs are mostly gone from mature applications and the interesting ones live elsewhere. These four spots produce the most findings, roughly in order of yield.

• JSON request bodies of internal APIs. Single-page applications send far more parameters than the URL shows. An endpoint like PATCH /api/v2/profile carrying {"user_id":4417,"email":"..."} is the highest-value target on most sites, because the front end always sends the correct ID and nobody tested what happens when it does not.
• Export, download, and report endpoints. Frequently bolted on later by a different team, and frequently skipping the authorization middleware the main app runs. GET /reports/download?ref=Q3-4417.pdf is worth ten minutes of anyone's time.
• Custom headers the client controls. Some APIs pass tenancy or identity in headers such as X-Account-Id. If the server reads that header instead of deriving the account from the session, you have an IDOR that never appears in the URL or the body.
• Nested and secondary IDs. A request like GET /api/teams/12/members/4417 often validates that you belong to team 12 and then trusts the member ID completely. Changing the outer ID gets a clean 403; changing the inner one gets the record. Test every identifier in a path, not just the last.

GraphQL deserves its own mention. A single node(id: "...") query can expose objects the REST API guards properly, because authorization was written per-endpoint and GraphQL collapsed a hundred endpoints into one. If a target runs GraphQL, start there.

How to Test for IDOR Vulnerabilities

How do you test for an IDOR vulnerability? Create two accounts, capture the requests account A makes to its own resources, then replay each request using A's session cookie and B's identifiers. Any response that returns B's data or changes B's state is an IDOR. Two accounts is the whole methodology, and it is the part scanners cannot do for you.

1. Register two accounts and keep them separate. Use two browsers or two containers so the sessions never mix. Create one distinctive object in each (a ticket titled "canary-B", say) so you know instantly whose data you are looking at.
2. Proxy everything and build a map. Browse the whole application through an intercepting proxy as account A, then read the history and write down every parameter that looks like an identifier. Our Burp Suite tutorial covers getting the proxy and browser talking if you have not set one up before.
3. Swap in Repeater, one request at a time. Replace A's object ID with B's and compare responses. Then repeat the exercise with no session cookie at all, which occasionally turns up unauthenticated access nobody expected.
4. Automate the boring part. Burp's free Autorize extension replays every request you make through a second account's session and flags the ones that should have been blocked. It turns an afternoon of manual swapping into a list you review in twenty minutes.
5. Check the write and delete paths too. A locked-down GET tells you nothing about the matching PUT. Different developers wrote them on different days.

One habit worth building early: log the exact request pairs as you go. A report showing request A (your account, your record, 200) beside request B (your session, their record, 200) gets triaged fast. A report that says "I could see other users' data" gets closed as "need more info".

Fixes That Are Not Fixes

When a team gets an IDOR report, the first instinct is usually to make the identifier harder to guess. That instinct is wrong, and knowing why is what separates someone who understands the bug from someone who memorized it. Unguessable is not the same as unauthorized.

• Switching to UUIDs. Random identifiers raise the cost of enumeration, which is genuinely useful, but they are not a permission check. UUIDs leak constantly: through shared links, referrer headers, CSV exports, support screenshots, and the app's own search results. Once one leaks, the endpoint that never verified ownership still does not verify ownership.
• Encoding the ID. A parameter of NDQxNw== looks opaque for about four seconds. That is base64 for 4417. Hashing is barely better when the hash is unsalted: an ID of b1d5781111d84f7b3fe45a0852e59758cd7a87e5 is just the SHA-1 of a small integer, and anyone can precompute the first million.
• Checking on the client. If the browser decides whether to show the edit button, the server still has to decide whether to honor the request. Attackers do not press buttons, they send requests.
• Blocking one HTTP method. Denying POST /admin/records/4418 while PUT and DELETE sail through is a real pattern in real code, usually caused by a route-level rule that listed methods by hand.

A second category is the filter a small change slips past. id=4418 may be blocked while id[]=4418 arrives as an array and takes a different code path, and sending both id=4417&id=4418 picks different winners in different frameworks. These are not clever attacks. They are evidence the application is validating a shape instead of checking a permission.

What Real IDOR Breaches Have Cost

IDOR gets treated as a beginner bug, which undersells it badly. In July 2023, CISA, the NSA, and the Australian Cyber Security Centre published a joint advisory titled Preventing Web Application Access Control Abuse specifically because of the damage this one class of flaw kept causing. Three of the incidents it documents:

• 2019: over 800 million personal financial files exposed at a US financial services organization.
• 2021: hundreds of thousands of mobile devices exposed through stalkerware applications containing IDOR flaws.
• 2012: personal data of more than 100,000 mobile device owners taken from a communications sector website.

The 2019 case is the one every web tester should know. First American Financial Corporation, a Fortune 500 title insurer, ran a document-sharing system that numbered closing documents sequentially. Anyone holding a link to one could edit the number and read the next, and the exposed set reached back to 2003: Social Security numbers, bank details, driver's license scans. Per the SEC's June 2021 enforcement action, the company's own security team had documented the flaw during a manual penetration test months before it became public and it was never remediated in line with policy. First American paid $487,616 to settle the disclosure-controls charge.

The useful part is that sequence. The bug was found internally, by a person, doing exactly the two-account exercise described above. Then it sat there. The technical flaw was one missing check; the expensive failure was organizational.

The class has not gone anywhere. Broken Access Control is A01 in the OWASP Top 10 2025, built from 40 mapped CWEs, roughly 1.84 million recorded occurrences, and 32,654 associated CVEs. OWASP ranks the API form of it first in the API Security Top 10, rating its prevalence widespread and its exploitability easy.

How to Fix an IDOR Vulnerability

How do you fix an IDOR? Look up the object, then verify that the authenticated session is allowed to have that specific object, before you return anything. The check belongs on the server, in the same place the data is fetched, and it must use the identity from the session rather than any value the client sent.

Concretely, this is the difference between vulnerable and fixed:

# Vulnerable: the ID decides everything
ticket = Ticket.get(request.params["id"])
return ticket.to_json()

# Fixed: ownership is part of the lookup
ticket = Ticket.get(request.params["id"])
if ticket is None or ticket.owner_id != session.user_id:
    return http_404()
return ticket.to_json()

Returning 404 rather than 403 on a failed check is a small touch worth adopting. A 403 confirms that record 4418 exists, which hands an attacker a working existence oracle even when the data stays hidden.

• Deny by default. Resources start closed and open only through an explicit rule. A new endpoint someone forgot to protect should fail shut, not fall open.
• Put the check where the data is. A gateway that confirms a valid session is not authorization. If the only check lives at the edge, every internal service call runs unguarded.
• Centralize the policy. One authorization layer that every request passes through beats per-endpoint checks copied by hand, because copies drift and one of them will be wrong.
• Alert on the pattern, not the request. One 403 is a typo. Four hundred of them walking consecutive IDs from one session is enumeration in progress, and it should page someone.

Add a regression test while you are in there. A test that logs in as user B and asserts a 404 on user A's object costs about six lines and stops the flaw returning the next time someone refactors the controller.

IDOR vs BOLA vs Broken Access Control

Three terms, one underlying failure, different scopes. Getting them straight makes reports and interviews go smoother.

Broken Access Control is the umbrella category. It covers every authorization failure: reaching an admin page you were never granted, escalating a role, tampering with a request method, and IDOR. Our broken access control guide maps the full set.

IDOR is one specific type inside that umbrella: an object reference the user controls, fetched without an ownership check. Every IDOR is a broken access control flaw. Most broken access control flaws are not IDORs.

BOLA (Broken Object Level Authorization) is what OWASP calls IDOR in its API Security Top 10, where it ranks first. Same bug, API-flavored name. If a triager reclassifies your IDOR report as BOLA, nothing changed except vocabulary.

Legal and Ethical Considerations

• Test only on systems you own, on purpose-built labs, or inside the written scope of a bug bounty program or engagement.
• Use two accounts you control. Confirming an IDOR against a real stranger's record means you have accessed a real person's data, even by accident.
• Stop at proof of impact. One record, screenshotted, is a report. Iterating through the ID range is a breach, and program rules say so explicitly.
• If a response contains personal data you did not expect, do not save it. Note the request, the status code, and the field names, then say so in the report and give the team time to fix it before writing anything public.