IDOR / BOLA: reading another user's data
IDOR (Insecure Direct Object Reference), also called BOLA (Broken Object Level Authorization), is when your app hands back a record just because someone asked for it by ID, without checking that they own it. Change /invoice/1001 to /invoice/1002 and you are looking at another customer's invoice. It is the most common serious flaw we find in vibe-coded apps.
What it looks like
Your app fetches data by ID: an order, a profile, a document, a message. The AI that built it wired the fetch to the database but never added the check that the logged-in user is allowed to see that specific row.
Because the app looks fine when you use it as yourself, this bug is invisible in normal testing. It only shows up when a second user asks for the first user's ID.
Why it matters
This is a direct data breach. Anyone with an account can walk through IDs and read every other user's records: personal details, payments, private messages, uploaded files. There is no exploit chain and no special tooling required, just a changed number in a URL or request.
How ArgosX detects it
ArgosX signs in as two separate users and replays one user's ID-bearing requests as the other. If user B receives user A's record, that is a confirmed cross-user leak, and the report carries the screenshot and the exact request that proved it. This is confirmation, not a guess from reading your code.
How to fix it
Every read and write that takes an ID must check ownership on the server, not just hide the link in the UI.
- On Supabase: enable Row Level Security on the table and add a policy that matches the row's owner to the requesting user.
- On a custom backend: add an ownership check in the handler (does this record's user_id equal the authenticated user's id?) before returning it.
- Never rely on the frontend hiding a button. If the API answers, the data is exposed.
Common questions
Is IDOR the same as BOLA?
Effectively yes. IDOR is the classic web term; BOLA (Broken Object Level Authorization) is the API-era name from the OWASP API Security Top 10. Both describe an app returning an object to someone who should not be allowed to see it.
Do random IDs (UUIDs) protect against this?
No. Hard-to-guess IDs raise the bar but do not fix the bug. If the endpoint returns the record whenever a valid ID is supplied, without checking who is asking, the data is still exposed the moment an ID is leaked, cached, shared, or found in a log. The fix is the ownership check on the server, not the shape of the ID.
Check your own app for this, free.
A free scan runs in minutes, no signup. Where it finds this, it proves it with the request and screenshot, not just a maybe. A human-verified pass is available when you want a person to confirm every finding.