AI App Users See Each Other's Data

What you noticed, and how serious it is

The reports tend to sound alike. One customer sees another customer's name on an invoice. A list that should hold three bookings holds every booking in the system. Someone changes a number in the page address and a stranger's profile opens. Or nobody has reported anything, and you have a nagging doubt because the app has only ever been used by you.

How serious it is depends on two things: whether the data belongs to real people, and whether a stranger could reach it or only someone already signed in. An app with test data and no public sign-up has a bug to fix before launch. An app with paying customers and open registration has a problem to contain today, and the section on exposed customer data further down is where you should go first. The table sorts the common cases.

What you noticed, what it usually means, and a check that uses only your own accounts

What you noticed: A list shows everyone's records
What it usually means: The app asks for the whole table and nothing where the data is stored narrows the answer to the signed-in person
A check with accounts you own: Add one record in each of your two test accounts and see whether either list shows both

What you noticed: Changing an id in the page address opens another record
What it usually means: The page loads whatever record is named and never asks who owns it
A check with accounts you own: Copy the address of a record from test account A and open it while signed in as test account B

What you noticed: One user can edit or delete another's record
What it usually means: Reading was restricted and writing was left open, or the other way round
A check with accounts you own: From test account B, try to rename and then delete the record that test account A created

What you noticed: A signed-out visitor can open a private page
What it usually means: The screen is tucked out of the menu and the data behind it answers anyone
A check with accounts you own: Open the page address in a private browser window without signing in

What you noticed: Staff or admin screens open for an ordinary account
What it usually means: The role is checked when the menu is drawn and nowhere after that
A check with accounts you own: Paste the admin page address into the browser while signed in as an ordinary test account

What you noticed: Uploaded files open from a link with no sign-in
What it usually means: File storage has its own access settings, separate from the tables
A check with accounts you own: Upload a file as test account A, copy its link, and open it signed out

What you noticed, what it usually means, and a check that uses only your own accounts
What you noticed	What it usually means	A check with accounts you own
A list shows everyone's records	The app asks for the whole table and nothing where the data is stored narrows the answer to the signed-in person	Add one record in each of your two test accounts and see whether either list shows both
Changing an id in the page address opens another record	The page loads whatever record is named and never asks who owns it	Copy the address of a record from test account A and open it while signed in as test account B
One user can edit or delete another's record	Reading was restricted and writing was left open, or the other way round	From test account B, try to rename and then delete the record that test account A created
A signed-out visitor can open a private page	The screen is tucked out of the menu and the data behind it answers anyone	Open the page address in a private browser window without signing in
Staff or admin screens open for an ordinary account	The role is checked when the menu is drawn and nowhere after that	Paste the admin page address into the browser while signed in as an ordinary test account
Uploaded files open from a link with no sign-in	File storage has its own access settings, separate from the tables	Upload a file as test account A, copy its link, and open it signed out

Hiding a button does not stop anyone reading the data

Your app has two halves. The half people see runs in their browser or on their phone. The half that keeps the records runs somewhere else, and the visible half sends it requests: give me this customer's orders, save this change. Anyone using the app can watch those requests with tools that ship inside every browser, and can send the same request with a different customer's id typed in.

So a screen that leaves out the Delete button, or a menu that omits the admin link, changes what a polite user sees. It changes nothing about what the stored data will hand over when asked. If the only thing separating two customers is that the app never draws a link between them, they are not separated.

AI builders produce this gap often, and for an understandable reason. You asked for a dashboard that shows a user their own orders, and the tool built a screen that does that. With one account in the database, a screen that filters correctly and a database that refuses correctly look identical, and the difference only appears with the second customer.

The rule has to live where the data is stored

A rule that holds is one the storage itself applies to every request, whatever screen or script the request came from. In plain terms, each table needs an answer to four questions: who may read a row, who may add one, who may change one and who may remove one. For most products the answer starts with ownership. A row carries the id of the account it belongs to, and the database returns it only to that account.

Many AI-built apps keep their data in a hosted database that supports rules of this kind on each table. The same idea applies when your app talks to its own server instead: the server has to work out who is asking from the sign-in session and check ownership before it answers. It must never trust an account id that the browser sends along with the request, because the person at the browser can change it.

Products with teams, staff or admins need one more layer. Write out each kind of user and what they may do with each kind of record before anyone touches the rules. A clinic owner sees every appointment at that clinic and none at another. A staff member sees today's list and cannot export it. That written list is what the rules are built from, and it is also what you test against afterwards. Our guide to launch security goes further into building that list.

Is my AI-built app secure enough to launch?

How to test it safely with two accounts you own

You can find out where you stand without reading code. Register two accounts yourself, using two email addresses that belong to you, and call them A and B. Put made-up data in both. Then run the steps below and write down the result of each one, including the ones that pass.

Stay inside those two accounts. Do not open, guess at or change a record that belongs to a real customer in order to prove the problem exists, even in your own product. You may have no right to look at it, you could alter something you cannot put back, and the test accounts will show the same fault. If the fault is there for A and B, assume it is there for everyone.

As A, create one record of each main kind your product stores: an order, a message, a file, a profile.
As B, look through every list and search box for anything A created.
Copy the address of one of A's records and open it while signed in as B.
As B, try to change A's record and then delete it. Sign back in as A and see whether it survived.
Sign out completely and open the same addresses in a private window.
If your product has roles, repeat the steps with an ordinary account against an admin page.
Record what happened at each step, with the time, so a repair can be checked against the same list.

One leak, found and closed with test accounts

Illustrative example

This example is illustrative. It was written to show the steps and does not describe a client.

What was reported: A dog-walking scheduler has a handful of early customers. One of them writes to say the visit history shows an address that is not theirs.
First hour: The founder turns off new registrations, leaves the logs alone and makes two test accounts with invented pets and addresses.
What the test showed: Account B's history lists account A's visits. The page asks for all visits and sorts them in the browser. Signed out, the same request returns nothing.
What was reachable: Visit dates and addresses were readable by any signed-in customer. Payment details were held by the payment provider and were not in that table.
Repair: A rule on the visits table returns a row only to the account that booked it or the walker assigned to it. The page was changed to ask for the signed-in customer's visits only.
Retest and follow-up: A and B each see their own visits, neither can edit the other's, and a walker account sees assigned visits only. The founder then takes advice on whether the customers have to be told.

What to do right now if real customer data may be exposed

If real people have accounts and the test shows their records could be reached by others, containment comes before repair. Stop new sign-ups, or take the affected part of the product offline, until the rule is fixed and retested. A maintenance notice for a day costs less than a second group of customers joining a product you already know is leaking. If the whole app is affected and you cannot isolate a part, take the whole app down.

Do not delete logs, and do not wipe the database to make the problem go away. The logs kept by your host, your database and your sign-in service are the only record of whether anyone used the gap, and you will need them to answer that question honestly. Save copies somewhere separate. Write down what you found, when you found it and each thing you did afterwards, with times.

Then find out what was reachable. List every table and file store the fault touched, what kinds of information sat in them (names, addresses, health or payment details, private messages), from what date, and whether a signed-out visitor could reach it or only a signed-in one. Being able to reach data and someone having taken it are different findings. The logs may tell you which you have, and an engineer can help you read them.

Get advice on whether you must notify anyone. Duties to tell affected users, a regulator or a business customer depend on where you are, where your users are, what kind of data was involved and what your own terms and contracts promise. Some of those duties come with deadlines that start when you become aware of the problem. This page is not legal advice and cannot tell you which rules apply to you. A lawyer who handles privacy matters can, and that conversation goes faster when you bring the written record described above.

Fixing it, and when to bring in an engineer

With test data only, you can try the repair in your builder. Ask for one table at a time, describe the rule in terms of ownership, and run the full two-account list again after each change. Tightening access commonly breaks a screen that had been relying on the open table, so expect a list to come back empty and treat that as the next thing to trace. Keep a saved version from before you started.

Bring in an engineer when real customer data was reachable, when the product has roles or teams and you cannot state the rules for each, or when a repair on one table keeps opening or closing another. Access rules interact, and a reviewer reads all of them together with the queries that depend on them. Our Diagnostic is a fixed-price written plan: we read the code and the database, list what is reachable by whom, and set out the repairs in order, with the fee credited to the build if you go ahead with us. The work happens in your accounts, and your repo and accounts stay yours.

Before you reopen sign-ups

Have each of these in writing. Together they show the gap is closed and give anyone advising you the facts they will ask for.

The two-account test results from before the repair and after it, step by step.
For each table and file store: who may read, add, change and remove a record.
The same test run signed out, and run with each role your product has.
Copies of the logs covering the period the gap was open, stored outside the app.
A dated note of what was reachable, by whom, and what you did about it.
The advice you received on notification, and who gave it.

How we can help

We can close the gap between your users' data.

Book a free consultation and tell us what you saw and whether real customers are signed up. We will say whether it sounds like a repair you can make in your builder or one that needs the Diagnostic. If we do the work, we write the rules where the data is stored, test them with separate accounts for every role, and give you the written results.

Book a free consultation

On the project call, we’ll discuss the problem, your existing tools and what TDAT should take off your hands. Then we can define the scope and next steps.

Or call (919) 289-1231

Questions before we start

How do I know if users of my app can see each other's data?

Create two accounts with your own email addresses, add made-up records in the first, and look for them while signed in as the second. Then open the address of one of the first account's records from the second account, and again while signed out. If any of those shows the record, the data is not separated.

The screen only shows each user their own records. Is that enough?

No. The screen decides what is displayed, and the stored data answers requests from anywhere. If the database or server does not check who is asking, a person can request another customer's records directly. The check has to happen where the data is kept.

Can I ask the AI tool to fix the access rules?

You can, and for a simple product with test data it is a reasonable first attempt. Ask for one table at a time and retest with two accounts after each change. For a product with real customers, roles or teams, have a person read the finished rules, because a rule that looks right can still leave one path open.

Do I have to tell my users if their data was exposed?

It depends on where you and your users are, what kind of data it was, and what your terms and contracts say. Some places set deadlines. We are not lawyers and this is not legal advice. Keep your logs, write down what was reachable and when, and speak to a lawyer who handles privacy matters.

Should I test by trying to open a real customer's account?

No. Use only accounts you created yourself with made-up data. Opening a real customer's records may be something you have no right to do, and it adds nothing: if the fault shows between your two test accounts, it applies to everyone.

What does TDAT need to review data access in my app?

Access to the code and the database in your own accounts, the address of the live app, and the list of user types with what each should be able to do. We agree the access with you first, limit it to what the review needs, and work with test accounts.