Your Supabase database can be read by anyone

Critical Whole domain Security

General instructions. Open this article from your PageCheck report to see it filled in with your domain's records and your DNS host's exact steps.

What it is

Your site keeps its content in a Supabase database. The page reaches that database with a public key that is part of the page's code, so every visitor's browser has it. That key is meant to be public — what protects the data is a set of access rules on each table (Supabase calls this Row Level Security).

What is wrong

Your Supabase database answers the public key and lists its tables, so Row Level Security is off or incomplete. Anyone who opens your site can read, and often change or delete, the data behind it.

How to fix

1. Turn on access rules for every table. In the Supabase dashboard, open Authentication → Policies (or Table editor → each table → Row Level Security) and switch Row Level Security on for every table in the public schema. With it on and no policy, the public key can read nothing.

2. Add a policy only for what the public needs. If part of a table really is public (for example a list of products), add a policy that allows reading just those rows and columns. Everything else stays private and is reached only by your own server-side code, which uses a secret key, never the key in the page.

3. Check it from outside. Open your site in a private browser window and confirm it still works, then re-run this check. You do not need to change the public key — it is meant to be public; the access rules are what protect the data.

Lock down my Supabase database: it is readable with the public anon key because Row Level Security is off.
Project: <my .supabase.co project>.

Steps:
1. List every table in the public schema and tell me which, if any, genuinely need to be readable by anonymous visitors.
2. Enable Row Level Security on every table in the public schema.
3. For the tables that must be public, add the narrowest SELECT policy that serves the site (only the needed rows and columns); leave the rest with no anon policy.
4. Make sure the app reads private data only through server-side code using the service_role key, never the anon key in the browser.
5. Give me the SQL for the policies and the exact dashboard steps, and tell me how to verify from an anonymous client that the private tables return nothing.
Do not rotate the anon key — it is public by design; the fix is the access rules.

Subject: example.com – our Supabase database can be read by anyone

Hi,

A website check (PageCheck) found that the Supabase database behind our site can be read with the public key that is in the page, because Row Level Security is off.

Please:
1. Turn on Row Level Security for every table in the public schema.
2. Add a read policy only for the data that genuinely must be public, and keep everything else private.
3. Confirm from outside that the private tables can no longer be read, and that the site still works.

The public key does not need to change — it is meant to be public. Thank you!

Check your site to see whether it has this problem. Check a website