Supabase table without Row Level Security

What actually happened

Supabase serves tables over a REST interface. Which rows someone may see is decided by Row Level Security — rules that live in the database and are evaluated on every request.

If Row Level Security is not enabled for a table, that check does not happen. The request is answered because the anon key is valid. That the asker is nobody in particular does not enter into it.

The anon key sits publicly in your frontend because that is where it belongs. Only the absence of rules turns it into a master key.

Fix it now

In the Supabase console under Authentication → Policies. Both statements belong together: the first locks, the second opens deliberately.

Warning: between `ENABLE ROW LEVEL SECURITY` and the first policy, your own app sees no data either. Do both in one go.

ALTER TABLE <table> ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Read own rows"
  ON <table> FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Update own rows"
  ON <table> FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

For every table, not just this one

Row Level Security applies per table. We report the tables we found — and we can only find the ones whose names appear in your frontend.

So check the Supabase console: under Table Editor a column shows which tables have RLS enabled. Anything holding personal data belongs protected, even if your app is not querying it right now.

Is this a reportable data breach?

If personal data is affected and it was genuinely publicly retrievable, then under Art. 33 GDPR usually yes, with a 72-hour deadline towards the competent supervisory authority. Notification can be waived if a risk to the individuals is unlikely — that assessment is a legal one, not a technical one.

If there is also a high risk, Art. 34 additionally requires notifying the affected people themselves.

This is not legal advice. When in doubt the case belongs in front of a lawyer — within the deadline, not after it.

Prove that it is gone

Repeat the query while signed out. If you now get an empty list or an error, the rules are working.

Then click through the app while signed in: rules that are too strict otherwise surface with your first customer.

If you unlocked the report, you can re-test the same domain as often as you like for 90 days. The second scan is the proof — for you and, should it come to that, for your incident documentation.

Frequently asked questions

How could someone reach my data without signing in?

Through the anon key that sits publicly in your frontend — which is by design. What is missing are the rules in the database that decide which rows someone may see. Without them Supabase answers every request that carries a valid key.

Do I need to rotate my anon key now?

No. The anon key is not the problem and is not secret. The hole is the missing rules. A new key would change nothing, because it would have to sit publicly in the frontend too.

How long was my table open?

That cannot be determined from the outside. The logs in your Supabase console and the table’s creation date give you something to go on. For incident documentation that is the decisive question — look there first.

Can I have it checked once I have fixed it?

Yes. Scan the same address again. After unlocking, that is possible as often as you like for 90 days at no extra cost, and every new report is fully visible right away.