Access rules explained: why your data may be open

Think of your database as a filing room, and your app as the receptionist who fetches files.

You’d assume the only way to a file is through the receptionist, who checks who you are. In many modern apps, that’s not how it works. To make the app fast, the browser on each visitor’s screen talks to the database directly. So the filing room needs its own lock on every drawer, and those locks are called row-level security, or access rules.

If the rules aren’t on, or they’re written wrongly, anybody who knows the address of the filing room can walk straight in. And every visitor’s browser has been told the address.

Why it happens

Many AI app builders use this direct-to-database pattern, frequently with a database service called Supabase. It’s a perfectly sound design when the rules are right. But an app with no rules works beautifully: all the screens load and all the tests pass. The app looks finished and nothing warns you, because from the inside nothing is wrong.

It can go wrong in several ways:

• the rules were never switched on for a table;
• they’re on, but say “anyone signed in can read everything”, so one customer can see all the others;
• a new table was added later, without any rules;
• the rules protect reading, but not changing or deleting.

What could happen

In the worst case, a stranger can download your entire customer list, or change it, without ever signing in, and it would look like normal traffic. If it holds personal data, you may have a reportable breach on your hands.

How to check

You can do the first two of these yourself.

1. Ask the tool. Most AI builders and database dashboards now have a security check or advisor. Run it, and read what it says. It’s a good start, but passing it doesn’t prove you’re safe, since a scanner can’t know who ought to see what in your business.
2. Try the second-customer test. Create two test customers. Sign in as one, and see whether anything from the other ever shows up. It won’t catch everything, but it catches some embarrassing failures.
3. Have someone try it from the outside. The real test is asking the database directly, without the app and without signing in. That needs someone who knows how, and it should only be done with your permission. It’s the first thing we check.

How to fix it

Every table needs rules saying who can read it, change it, add to it and delete from it. In plain terms, you decide things like “a customer can read only their own orders” and “only staff can change prices”, and then those decisions get written as rules. Your AI tool can often draft them. Have someone test them afterwards from the outside, because a rule that looks right can still let people in.

Questions

By Selwyn Doling, VibeTend. Last updated 6 November 2026.