Why your database lets everyone see everyone's data

If your database has no access rules, it answers any request it receives without asking who is there. Any user, sometimes any visitor, can then read or change rows that are not theirs. Access rules, often called Row Level Security, exist to say: "everyone sees only their own rows".

A database is a filing cabinet

A database is a large filing cabinet. Each table (customers, orders, messages) is a drawer, and each row is a card: one order, one customer, one message.

In many apps built with AI tools, the app talks directly to the database from the user's browser, with no server in between to filter. The app asks "give me my orders", but nothing guarantees the database would not also answer "give me all the orders".

It is like a cabinet whose drawers are not locked: you only have to ask, or help yourself, to read everything. The screen only shows your cards, but the drawer itself is open.

What access rules do

Access rules are set on the database itself, row by row. They ask questions like:

• does this row belong to the person requesting it?
• may this person read it, change it, delete it?
• is this person an administrator?

With such rules, even if someone bypasses the app's screen and talks straight to the database, it refuses to show what is not theirs. It is a standard feature of some database systems: it exists so that protection does not depend on the screen.

Why it is so often misconfigured

• The rules are turned off, because without them everything works right away. This is the most common situation in a prototype.
• The rules exist but are too broad: "any signed-in user can read everything", which means every customer sees the others.
• A rule was added to fix a bug, then never tightened again.
• The screen is correct, so nobody suspects the database is less so.

In all these cases, the app "works" and passes every test done by hand.

How to test without being a developer

1. Create two accounts (A and B) and add a piece of data in each.
2. Signed in as A, see whether an address, an identifier or an export lets you view B's data. Changing a number in an address is often enough to test.
3. Signed out, try opening pages or lists that should require an account.
4. Ask the person who built the app whether access rules are enabled on every table, and what each one says.

If any of these attempts succeeds, do not treat it as a detail: your users' data is readable.

What this means for you

A leak of this kind requires no hacking skill: a simple request is enough. The consequences are serious: loss of trust, legal obligations toward your users, and sometimes heavy fallout. Better to find out before a stranger does.

This flaw is the first in the catalogue of typical flaws in AI-built apps, and one point of the launch checklist.

Remember

A database without access rules answers everyone: it is up to the database, not just the screen, to say who sees which row.

And for your product?

An audit looks, among other things, at what each type of user can read, write or delete, and hands back a report ranked by severity. If you want to know whether your data is properly separated, we can discuss it in a 30-minute call.