What is IDOR? The bug AI loves to write
IDOR, short for insecure direct object reference, is one of those vulnerabilities that sounds technical and is actually embarrassingly simple. It is also everywhere, it is genuinely dangerous, and it is exactly the kind of mistake an AI coding assistant produces without blinking. If you only learn one vulnerability class, make it this one.
How it works
An application exposes an object, an invoice, a user record, a file, by a reference such as an id in the URL or request. The endpoint fetches the object by that id but forgets to check that the object actually belongs to the person asking. So a user requesting /invoices/1001 changes it to /invoices/1002 and sees someone else's invoice. That is the entire bug. It is cataloged as CWE-639, and it is a flavor of the broader broken access control category that tops the OWASP Top 10.
Why it is so dangerous
Because it is invisible on the happy path and catastrophic off it. The feature works perfectly in the demo: every user sees their own data. The flaw only appears when someone changes the id, and when they do, the blast radius is often every record in the table. No exotic skills required, just curiosity and an incrementing number. Some of the largest data exposures in recent years were, at root, an IDOR.
IDOR is the vulnerability of forgetting to ask one question: is this actually yours? The code that forgets runs perfectly until someone else asks for your data.
Why AI-generated code is full of it
An AI assistant is excellent at generating an endpoint that fetches a record by id and returns it. That code compiles, passes the test the assistant also wrote, and ships. The missing piece, scope this query to the authenticated caller's tenant, is exactly the kind of adversarial check that does not appear on the happy path, so it is exactly what the model omits. And because the model reproduces the same pattern across every similar endpoint, one IDOR is rarely alone. We dig into that dynamic in what AI-generated code gets wrong about security.
How it gets found
A scanner struggles with IDOR, because telling an authorized request from an unauthorized one requires understanding who should be allowed to see what, which is application-specific context. Finding it reliably means testing authorization directly: authenticate as one user, try to reach another's objects, and prove the boundary either holds or does not. That requires accounts at different privilege levels, which is one more reason to give your testers real access.
Uvy tests authorization the way it actually breaks: with multiple accounts, systematically probing object-level access across the application's endpoints, and proving each IDOR with the exact request that crossed the boundary. See how it works.