Is your Supabase data exposed? A 15-minute check for AI-built apps

Apps built with AI tools usually talk to Supabase directly from the browser. That is a normal, supported setup, but it only stays safe if the database itself decides who can see what. When that part is missing, any visitor who opens the browser's developer tools can read or change data that belongs to other users.

Here is a check you can do yourself in about 15 minutes.

Why the browser key isn't the problem

Your app ships with a Supabase URL and a public key (often called the anon or publishable key). Everyone can see it, and that is by design. Security comes from Row Level Security (RLS): rules in the database that decide which rows each request may read or change. A table with RLS turned off is open to anyone holding the public key.

Check 1: Is RLS on for every table?

In the Supabase dashboard, open the Table Editor and look at each table in the public schema. Any table marked as unrestricted or with RLS disabled needs attention. The Security Advisor in the dashboard also lists these warnings.

Check 2: Are the rules too loose?

RLS can be on and still let everyone in. A policy that uses true as its condition allows every request. Look at each policy and ask: who should be able to read this row, and who should be able to change it? A typical rule for a profiles table looks like this:

alter table profiles enable row level security;

create policy "Users read own profile"
  on profiles for select
  using (auth.uid() = id);

create policy "Users update own profile"
  on profiles for update
  using (auth.uid() = id);

Tables that link to a user through a column such as user_id use the same pattern with auth.uid() = user_id.

Check 3: Is a secret key in your frontend?

Supabase also has a secret key (the service role key) that skips RLS completely. It must only ever live on a server. Search your code and your host's environment variables for service_role or a variable holding the secret key. If it was ever in frontend code or a public repository, treat it as leaked: rotate it in the project's API settings and update your server functions.

Check 4: Storage buckets

Files have their own rules. Open Storage and check which buckets are public. Profile pictures may be fine as public. Invoices, ID documents and uploads usually are not, and need policies like your tables.

Check 5: Test it as two users

Create two test accounts. Log in as the first, create some data, then log in as the second and try to see or change it, including through the browser's network tab. If the second user can see the first user's data, a policy is missing.

Check 6: Backups

Look at your project's backup settings and your plan's backup options. Before real users arrive, make sure you have backups and know how to restore one.

What to do if you find a problem

Turn RLS on first, then add the policies your app needs, then test with two users again. If the app stops working after RLS is on, that shows which queries relied on open access. Fix the policy, not by turning RLS back off.

If you'd rather have someone else check it, our AI App Security Check covers all of this and fixes what it finds.