IDOR checker for SaaS apps: can one customer see another customer's data?
You've heard the term IDOR and you're not entirely sure if it applies to you. Here's the concrete version: can a second logged-in account see the first account's data, just by changing a number in a request?
Changing /invoice/1042 to /invoice/1043
Insecure Direct Object Reference (IDOR) is the term for a specific, very common gap: an endpoint uses an id straight out of the request — a URL, a query parameter, a JSON body — to decide what data to return, without checking that the id actually belongs to the person asking.
GET /invoice/1042
→ 200 OK { "id": 1042, "owner": "you@yourcompany.com", "total": "$430.00" }GET /invoice/1043
→ 200 OK { "id": 1043, "owner": "someone-else@theirs.com", "total": "$1,240.00" }No password guessing, no exploit code — a working login and a number typed into the address bar. The same shape shows up on API routes, downloadable PDFs, admin panels, and “my account” pages built from a database id instead of checking session ownership.
The most common finding in AI-generated apps
This isn’t specific to any one AI coding tool, and no credible source publishes a reliable percentage for “how many vibe-coded apps have an IDOR” — be skeptical of any site that quotes one. What is a well-documented general pattern: tools optimized for “does the feature work when I’m logged in as myself” have no reason to generate the check “does this still work when I’m logged in as someone else, asking for my data.” The happy path — you log in, you see your own invoice — passes every test that only ever uses one account. The bug only exists from a second account’s point of view.
It requires two real logged-in accounts, not one
A scanner that reads your source code or your API’s shape can flag “this route takes an id parameter” as suspicious, but it can’t tell you whether the server actually checks ownership — that only shows up by trying it. A scanner that crawls your app logged out can’t reach the route at all, since it requires a session. Proving an IDOR needs a second account, genuinely signed in, genuinely trying to read the first account’s row — which is exactly the setup most automated tools skip, because it’s more work to build than a rules pass.
A1: the two-account engine replays the request itself
This is the check Solacess is built around. It creates two real test accounts on your live app, logs in as the first, notes what it can see, logs in as the second, and replays the first account’s requests with its own session — swapping the id where one appears.
If A’s data comes back to B, the finding is marked verified and shown with the redacted request and response — not a guess about a route’s shape, the actual proof. The report also names the table or route affected, so the fix is specific: add an ownership check to that one query, not “review your authorization logic.”
A manual version, if you want to try it first
- Create two throwaway accounts on your own app — never real customer accounts.
- Log in as the first, find any URL, API call, or downloadable file that includes an id you own (an invoice, an order, a project).
- Log in as the second, and either change the id in the URL or replay the first account's exact request with the second account's session/cookie.
- If the second account's data comes back — or worse, the first account's — that route needs an ownership check before it ships.
Read the A1 finding that opens its own evidence.
The sample report is a real scan of a deliberately vulnerable app — nine findings, the proof behind each one, and what they would cost.