Supabase anon key exposed: what it allows and how to test RLS

Which Supabase keys are meant to be public?

Supabase's API keys page documents two pairs. The legacy pair is the anon and service_role keys. The newer pair is the publishable key (starts with sb_publishable_) and the secret key (starts with sb_secret_). In each pair, the first is for clients and the second is for servers. We checked the docs on October 24, 2026.

Both kinds of key can be read by anyone who downloads the app. Expo says it plainly: variables that start with EXPO_PUBLIC_ are visible in plain text in your compiled application. That is why the anon key can ship, and why a secret key cannot. If Newly built your app, you can download the code or connect your own repository and search it for every key.

What decides whether the anon key can read a table?

The Data API is built on PostgREST. It reads the role in your token and switches to the database role with that name for the request. It authenticates, and the database authorizes. Two layers then apply, and Supabase's Data API security page names both: grants decide which roles can reach a table, view or function, and RLS policies decide which rows those roles can read or change.

Two sentences from the docs matter most. On a table without RLS, the page says tables and views exposed through the Data API can be accessed by any role with matching grants. And the same page lists the default grants on new objects in the public schema for anon, authenticated and service_role, with Supabase stating it is changing the platform default so that exposure becomes opt-in. As of October 24, 2026 the docs describe that as a change under way, so check your own project's Data API settings instead of assuming.

The other half is the RLS guide: with RLS enabled and no policies, no data is accessible through the API with a publishable key until you create policies.

How do I test each table as anon?

Checking that RLS is switched on is half of it. A policy can be on and still wrong, so read the tables the way the public key would. Use only your own project.

1. Read every table as anon (5 minutes)

In the Supabase SQL editor, switch role inside a transaction and roll it back, as the RLS guide shows with set local role. Repeat for every table in every schema the Data API exposes.

begin;
set local role anon;
select count(*) from public.your_table;
rollback;

A table with no rows tells you nothing, because zero is the answer either way. Put one test row in it first, or test a table that already has data.

2. Try the writes as anon (3 minutes)

In the same rolled back transaction, attempt an insert, an update and a delete on each table that holds user data. All three should fail. A write that succeeds leaves the table open to anyone with the app.

3. Read as a second user (5 minutes)

Anon is the stranger. The more common mistake is one signed-in user reading another's rows, which OWASP calls broken object level authorization. Create two test accounts, put a row in the first, and request it as the second. The RLS guide shows how to set the user identity in SQL.

4. Open the advisor (2 minutes)

Supabase's database advisors include lint 0013, which says anyone with your project URL can read, edit and delete all data in a table that has RLS off, and lint 0007, where a policy exists but RLS is off, so the policy does nothing. A clean advisor is a hint, not proof, so keep the anon output too.

What does each result mean?

Which policies still let everyone in?

Turning RLS on is not the finish line. Read each policy for these patterns:

• A condition of true for anon. The RLS guide says a policy that reads to anon using ( true ) gives every unauthenticated visitor read access to every row the role can reach. Fine for data meant to be public, wrong for the rest.
• A policy that checks the user is signed in but not which rows are theirs. Every signed-in user then sees every row.
• A view over a protected table. The docs say that on Postgres 15 and above a view obeys the underlying policies when security_invoker = true, and the advisor flags views that bypass RLS (lint 0010) and views that expose user data (lint 0002).
• A table created later, by you or by an AI agent, in the same exposed schema. UpGuard reported that tables created programmatically through the API do not have RLS enabled by default, so repeat the test after every schema change.

What if a secret or service_role key was in my app?

Treat it as public, because it was. A secret key skips RLS, so RLS tests will not show the damage. GitHub's guidance for any leaked credential is that removing it from the code is not sufficient and the key must be revoked with its provider. Supabase's key guidance lists the order: create a new key, replace the old one everywhere, confirm everything uses the new one, then delete the old key. Fix the cause of the leak first, or the new key leaks the same way.

Then move the work that needs the key to a server you control, such as an edge function, and let the app call it with the signed-in user. The general runbook is in Red's guide to rotating secrets after a breach. If your logs show bots asking for /.env, the 30-second check tells you whether the file is actually served.

This test is one of six in the 15-minute check for AI-built apps. For the AI provider keys in your app, see rotating LLM provider keys, and OWASP's Mobile Top 10 lists improper credential usage as its first category. All pages sit under Security.

Where do you stand?

Every item starts as unknown. Move it to confirmed only when you hold the evidence listed under it, with the date you ran the test.

Frequently asked questions

Sources

All pages opened and checked on October 24, 2026.

1. API keys, Supabase docs
2. Using API keys, including rotation, Supabase docs
3. Row Level Security, Supabase docs
4. Securing your Data API, Supabase docs
5. Database advisors (lints 0002, 0007, 0010, 0013), Supabase docs
6. Everything, everywhere: systemic data exposure in Supabase apps, UpGuard, October 14, 2026
7. AI-built app exposed 18K users, researcher claims, The Register, February 27, 2026
8. Authentication and roles, PostgREST docs
9. API1:2023 Broken Object Level Authorization, OWASP API Security Top 10
10. OWASP Mobile Top 10, OWASP Foundation
11. Environment variables in Expo, Expo docs
12. Remediating a leaked secret, GitHub docs