Access and data

Stop one user reading another user’s data

The most common serious flaw in AI-built apps: a route that returns any record by ID. How to find it, fix it, and prove the fix.

9 min readChecks: AC-1, AC-4, AU-8

An AI coding tool asked to "load the invoice" writes a route that loads the invoice with that ID. It does not always add "and only if it belongs to you". The result is called an insecure direct object reference, and it is critical: anyone signed in can read anyone else’s data by changing a number.

Find it by hand

  1. Create two accounts, A and B.
  2. As B, create a record and note its ID from the URL or the network tab.
  3. Sign in as A and request B’s record by that ID, in the page URL and against the API route directly.
  4. If A sees B’s record, or can change or delete it, the check fails.

Fix it

Paste into your AI coding tool
Find every server route and server action that takes a record ID from the request. For each one, make the database query filter by the signed-in user (or their organisation) as well as the ID, so a record belonging to someone else returns 404. Take the user from the server session, never from the request body. List every route you changed and every route you checked and left alone.

Admin routes need the same care: the role must be checked on the server, never read from a flag the browser sends.

Prove it

Run the two-account test again on every route the prompt changed. Record the date and the result. That dated pass is the evidence a buyer can rely on.

All 77 checks, ranked by severity

The free checklist has every check in this guide and the rest, each with a fix prompt and a deadline.

Get the free checklist