What is IDOR?
IDOR, short for insecure direct object reference, is a type of broken access control bug. It happens when an app uses a user-supplied value, such as an ID in a URL or form field, to fetch a record. The app returns that record without confirming the user is allowed to see it. That gap matters because a single changed digit can hand one person another user's data, and it takes no special tools to try.
The flaw is common enough that standards bodies track it directly. According to MITRE's CWE-639, the weakness is "Authorization Bypass Through User-Controlled Key," which describes exactly this pattern of trusting a client-supplied reference. OWASP places it under Broken Access Control, the category that topped its 2021 Top 10 list.
Secure Coding Cheat Sheet
Build the server-side authorization habits that stop IDOR at the source with a practical secure coding checklist.
How does IDOR work?
Picture a banking app that shows your statement at a URL like /account?id=1001. If the server returns whatever record matches the ID without checking who is asking, then changing the value to 1002 may reveal a stranger's statement. The identifier points directly at the object, and nothing stands between the request and the data.
In code, the mistake usually looks harmless. The query fetches the record by ID but skips the step that ties the record back to the logged-in user.
@app.route("/account")
def account():
account_id = request.args.get("id")
# Fetches the record but never checks who owns it
return db.query("SELECT * FROM accounts WHERE id = ?", account_id)The safe version adds one condition: the record must belong to the session user. That check is what separates a working feature from an open door.
Like other common code vulnerabilities, IDOR shows up in a few recurring shapes:
Read access (horizontal privilege escalation): viewing invoices, messages, or profiles that belong to other accounts by editing an ID.
Write access: updating or deleting another user's object by pointing an action at their identifier.
Function-level access: reaching admin-only objects because the app checks the ID but not the caller's role.
What are the risks of IDOR?
The damage depends on what the object holds, and the range is wide. A read-only IDOR can leak personal data and break privacy commitments. A write-capable one lets an attacker change balances, reset settings, or delete records they never owned. Exposed applications are a leading way in, too: the Wiz Cloud Attack Retrospective found that 26% of breaches came from exploiting public-facing applications.
Data exposure: personal, financial, or health records reachable by anyone who can guess or increment an ID.
Account takeover: chaining an IDOR with a password-reset or email-change endpoint to seize other accounts.
Compliance fallout: exposed regulated data can trigger reporting duties under frameworks your team already answers to, such as SOC 2 or ISO 27001.
Because the traffic looks legitimate, these incidents often surface late. A firewall sees a valid session making valid requests, so nothing trips. The gap surfaces only when someone reviews access logs and spots one token pulling objects it should never touch.
Watch 5-min demo
See how Wiz Code connects application code to its live cloud deployment to surface risky access logic.
How do you prevent IDOR?
The good news is that the defense is well understood. It centers on one habit: verify authorization on the server for every object, every time. Treat that habit as one of your core application security controls, and most IDOR paths simply close.
Enforce server-side checks: confirm the logged-in user owns or may access the requested object before returning it, on every endpoint.
Deny by default: start each request with no access and grant it only when an explicit rule allows it.
Use indirect references where they fit: map a session-scoped handle to the real ID on the server, so clients never pass the raw key.
Test the access logic directly: pair static application security testing with dynamic application security testing that logs in as one user and tries to reach another user's objects.
Watch access patterns: alert on a single account or token requesting many sequential IDs or objects it does not own.
Notice what is missing from that list: hiding the ID. Long random values raise the effort to guess, but they do not replace the ownership check, which is the point of the next section.
Common pitfalls that leave IDOR open
The most frequent mistake is trusting obscurity. Teams swap sequential IDs for UUIDs and assume the problem is solved. But an attacker who finds a valid UUID in a shared link, a log, or a referrer header still walks in. The server skips the ownership check, so the long value changes nothing.
A second trap is inconsistent enforcement. One team adds the check to the web route but forgets the API that serves the same object. The flaw then survives on a path no one reviewed. In practice, coverage gaps between services are where IDOR quietly lives, which is why context across code and cloud matters so much.
Catch IDOR before it ships
Most IDOR bugs slip through because scanners treat code and cloud as separate worlds. No one can tell whether a weak authorization check sits on a service that is exposed and holding real data. Wiz Code closes that gap. It maps your application code to its live cloud deployment on the Wiz Security Graph. Now you can see which services face the internet, which handle sensitive data, and which access flaws to fix first. Wiz SAST scans the code path where an object is fetched and flags missing or inconsistent ownership checks.
Wiz AI-SAST reads code for context and intent instead of matching fixed rules. That lets it surface multi-step and business-logic flaws traditional scanners overlook, from IDORs and broken authentication to trust-boundary bypasses and weak IaC or secrets handling. Each finding then gains runtime and cloud context to cut the noise. When a risky endpoint is both exposed and reachable, that becomes a toxic combination your team can act on right away. The Green Agent can then open a pull request with a fix inside the tools developers already use. The result is fewer guess-and-check tickets and clearer answers about which access risks truly matter.
Want to see how code-to-cloud context surfaces exploitable access flaws? Get a demo to watch Wiz connect an exposed service to the sensitive data behind it.
See Wiz in action
Find and fix exploitable access-control flaws with full code-to-cloud context.
