Apps with a Supabase backend

What this finding means

Supabase gives an app a hosted Postgres database reachable over a REST and realtime API. An app that talks to it ships two things: the project URL and the anon key, a signed token identifying the project and the anonymous role.

Neither is a secret. The anon key is designed to sit in client code, exactly like a Firebase web config. Finding it in an APK is expected and is not, by itself, a leak.

We have recorded a Supabase reference in 85 apps. What the finding tells you is which apps depend on Supabase, so the one control that matters can be checked.

Row Level Security is the only thing standing in front of the data

Supabase exposes tables through PostgREST. With the anon key and a project URL, anyone can issue queries against any table the anonymous role is permitted to read. The permission boundary is Postgres Row Level Security, declared per table as policies.

The trap is the default. A table created without RLS enabled is readable and often writable by the anon role. RLS is not on until you turn it on, per table, and a policy-less table with RLS enabled denies everything while a table with RLS disabled allows everything. Enabling RLS on four tables and forgetting the fifth leaves the fifth fully open.

This differs from Firebase in a way that matters. Firebase has a single rules document covering the database, so an unprotected path is visible in one place. Supabase spreads the decision across every table, and new tables arrive from migrations, not from a security review.

How to fix it

• Enable RLS on every table in the public schema, including tables added later by a migration.
• Write explicit policies for each role. A table with RLS on and no policy denies all access, which is the safe starting point.
• Never ship the service_role key. It bypasses RLS entirely and belongs only on a server you control.
• Check views and functions as well as tables: a SECURITY DEFINER function can return rows the caller's policies would have blocked.
• Rotate the anon key if you have ever used it as though it were a secret, and treat the rotation as a release, since every installed client holds it.

Why we do not test this for you

Checking whether a Supabase project is actually open would mean sending its anon key to the service and seeing what comes back. That is authenticating with a credential found in someone else's app, and we do not do it — not to establish a finding, and not to make a report more compelling.

The line we hold is narrower: anonymous requests to resources whose owner configured them to answer anyone, using no credential at all. A Supabase project does not fall inside it, so these are reported as references and verified only on an authorized scan of your own app, where you are the one asking.