Broken Access Control
What an IDOR vulnerability is, and how to check your app in five minutes.
An IDOR, or insecure direct object reference, is when your app takes an ID from the request and returns the matching record without checking whether the person asking is allowed to see it. Change the ID, get someone else's data. It is one of the most common holes in AI-built apps.
The app shows you your data. The API shows anyone anything.
Your interface only ever requests your own records, so everything looks correct. But the request behind it carries an ID, and if the server hands back whatever that ID points to without checking ownership, then anyone who changes the number in the request reads another user's data. The front end never reveals this. It only shows when someone edits the request directly, which is exactly what an attacker does first.
A concrete example
Say your app loads an invoice at /api/invoices/1043. You are logged in, it is your invoice, everything is fine. Now an attacker logged into their own account changes 1043 to 1044 and sends the request. If the server returns invoice 1044 without checking that it belongs to the attacker, that is an IDOR. They can walk the numbers, one at a time or in a script, and download every invoice in the system.
The ID does not have to be a number. It can be a username, a file name, an account slug or a document key. The vulnerability is the same whenever the server trusts an identifier from the client to decide what data to return, without also checking who is asking.
Why AI-built apps get this so often
When an AI builder generates an endpoint, it writes the part that fetches the record by ID, because that is the obvious job. The part it reliably skips is the ownership check, the line that says this record must belong to the logged-in user or the request is refused. That check is invisible in the working app: with it or without it, your own data loads exactly the same. Only a second account trying to reach the first account's data reveals whether it exists.
This is why an IDOR causes no error, no crash and no visible symptom. The app looks finished and behaves perfectly, and the exposure sits there until someone goes looking.
The five-minute test
Create two ordinary accounts, A and B. Log in as A and open something that belongs to A, an order, a document, a profile, and note the ID or URL. Now log in as B and request A's item directly, by pasting the URL or replaying the request with A's ID. If B sees A's data, you have an IDOR. If B is refused, that endpoint is enforcing ownership.
Do this for each type of record that matters: anything with personal data, money or private content. It is the single most revealing test you can run on your own app, and it needs no special tools, just two accounts and the browser.
How to fix it
Every endpoint that returns or changes a record must check ownership on the server, not just fetch by ID. The rule is: does the record this ID points to belong to the account making the request, or is that account explicitly allowed to see it? If not, refuse. On backends like Supabase and Firebase, this is enforced with row-level security or security rules, so the database itself refuses to hand back rows the caller does not own, even if the application code forgets to ask.
Client-side checks do not count. Hiding a button or filtering a list in the browser does nothing, because the attacker sends the request directly and never touches your interface. The check has to live where the data does.
Common questions.
- What does IDOR stand for?
- Insecure Direct Object Reference. It means the app references a data object directly by an ID from the client and does not verify that the client is authorised to access that object.
- Is IDOR really that serious?
- It is one of the most damaging and most common access-control flaws, because it exposes real user data at scale with no special skill required. An attacker just changes an ID. It sits at the centre of the broken access control category, which is the most widespread serious finding in AI-built apps.
- How do I know if my app has one?
- Run the two-account test above: log in as one user and try to reach another user's records directly. If it works, you have an IDOR. If you want it done thoroughly across every endpoint, that is part of our security audit.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.