Apps built quickly with AI or low-code tools usually let the browser talk straight to a hosted database like Supabase or Firebase. That design choice is convenient, but it means a single layer, your access rules, decides who can read and write your data. If those rules were loosened during development and never tightened, the personal data your users trusted you with may be readable by anyone who knows where to look. Here is how to check yours in a few minutes, and how to fix it.
Why fast-built apps put the database on the front line
A traditional web app keeps a server in the middle. The browser asks the server for data, and the server checks who you are and what you are allowed to see before it answers. Tools that scaffold an app fast often skip that middle layer. The browser connects directly to the database service, which is quicker to build but removes the place where those permission checks normally live.
When the server in the middle is gone, the database's own access rules become the only thing standing between a visitor and your data. Get them right and the setup is perfectly safe. Leave them open and anyone can read the tables. In security terms this is a failure of authorisation, and it is the single most common serious flaw in web applications. It sits at the top of the current OWASP Top 10 as A01, Broken Access Control.
The public key is meant to be public
Here is the point that trips up most founders. Both Supabase and Firebase give your app a key that ships inside the browser bundle, where anyone can see it. That is by design. The Supabase anon key and the Firebase config key are meant to be public. They identify your project, they are not a password, and hiding them is not the control that keeps your data safe.
The control is the access rules on the data itself. So if you have been reassured that everything is fine because your keys are "not exposed", that is the wrong thing to be checking. Whether your data is private comes down to the rules, not the key.
Supabase: check Row Level Security
On Supabase, every table in the public schema is reachable through an automatically generated API using that public key. Row Level Security, or RLS, is the feature that decides which rows each request may see. With RLS off, anyone with your project URL and the anon key can read, and often write, every row in the table.
The trap is the default. RLS is switched on automatically only when you create a table through the dashboard Table Editor. Create a table with raw SQL, the SQL editor, or an ORM such as Prisma or Drizzle, and RLS starts off. Plenty of AI-scaffolded projects fall into exactly that gap. A disclosure in May 2025 catalogued hundreds of live endpoints across around 170 production apps that were readable by anyone holding the public key, exposing emails, addresses, and even API keys. One 2025 analysis of AI-generated apps found roughly one in ten had missing or misconfigured RLS.
How to check. Open your Supabase dashboard and look for the "RLS disabled in public" warning. It appears once per affected table. Remember that the app working normally tells you nothing, a table with RLS off serves your app happily while being open to everyone.
How to fix. Enable RLS on each flagged table, then add policies that let a user read and write only their own rows, typically by matching an owner column to the logged-in user. Avoid a blanket "always true" policy, which quietly reopens the table. Keep the powerful service role key on your server only, never in the browser. After fixing, load your app while logged out and confirm the private data no longer comes back.
Firebase: check your Security Rules
Firebase works differently in the detail but the same principle applies. When you create a Firestore database, a Realtime Database, or a Storage bucket, you choose between Locked mode, which denies everyone by default, and Test mode, which grants public read and write for thirty days. Test mode is the most common cause of Firebase leaks. Founders pick it to get moving, then either forget to lock it down or paste in a rule like allow read, write: if true to make a stubborn feature work, and it never gets tightened.
Two further traps are worth knowing. A rule that only checks request.auth != null confirms that someone is logged in, but not that the data belongs to them, so any signed-up user can read everyone's records. And your Storage rules are separate from your database rules, so locking one does not lock the other.
How to check. Open the Firebase console and read the Rules tab for each of Firestore, Realtime Database, and Storage. Look for anything that allows access if true, or that checks only that a user is logged in without checking the record is theirs. You can find the official guidance in the Firebase Security Rules documentation.
How to fix. Replace open rules with rules that require both that the request is authenticated and that the record belongs to that user. Set rules for Storage as well as the database. Test your rules before you deploy them, so a change to your access control is never an untested production change.
A five-minute check you can run today
You do not need to be a security specialist to do a first pass. Working through this list will catch the most damaging version of the problem:
- Open your backend dashboard and read the actual access rules. Do not judge by whether the app works, because an open database works perfectly for your app while being open to everyone.
- On Supabase, check for an "RLS disabled" warning on any table in the public schema. On Firebase, check whether any rule allows access
if true, or only checks that a user is logged in. - From a logged-out browser, try to load data that should be private. If it comes back without you signing in, treat that data as public until you have fixed the rules.
- Make sure your most powerful credentials, the Supabase service role key and any Firebase Admin service account, are only ever used on your server and never shipped to the browser.
- Make your fixes, then repeat the logged-out test to confirm the exposure is closed.
If you would rather have someone check it for you
Broken access control is common, high impact, and usually quick to remediate, which is exactly why it is worth catching before a customer, an investor, or a security questionnaire does. A short application security assessment finds this class of issue and the handful of others that tend to travel with it, and hands you a clear list of what to fix and how. If you have built something fast and want a second pair of eyes before more users sign up, tell us about it at secvura.com and we can help you find and fix what matters.