Security audits for Supabase apps.
Your Supabase data is protected by row level security and nothing else, because the public key ships in every visitor's browser by design. We audit the project table by table, test what that key really returns, and hand you the correct policy for each gap.
Why it matters
RLS enabled is where Supabase security starts, not where it ends. A policy of USING (true) shows as protected in the dashboard and restricts nothing. A SECURITY DEFINER view runs as its owner and bypasses policies entirely. A database function left callable with the public key hands out whatever it computes; we have found ones named generate_license_key and generate_transfer_token callable by anyone. And in apps we review, tables of bank account numbers, patient codes and stored authentication tokens have sat behind a published key with no policy at all. None of it shows a warning, and none of it breaks the app.
What you get.
RLS coverage, table by table
Every table checked for row level security being enabled, with writable-by-anyone treated as seriously as readable. We have seen orders, payments and even audit-log tables open to unauthenticated writes.
Policy correctness review
Enabled is not protected. We read every policy for USING (true) and similar no-ops, check SECURITY DEFINER views that sidestep policies, and confirm the anon and authenticated roles can each reach only what they should.
Live test with your own public key
We query the project unauthenticated with the anon or publishable key, exactly as an attacker would, then repeat the test between two signed-in accounts to confirm users cannot read each other.
Functions, storage and edge functions
Database functions callable with the public key, storage bucket policies, and edge functions deployed with JWT verification off that never added their own authorisation check in the body.
Key audit and legacy migration
Which keys shipped in your bundle, whether a service role key ever reached a client, and your legacy key status. Legacy anon and service_role keys cannot be rotated, so if one is exposed, migrating to the new publishable and secret keys is the fix, and we plan it with you.
Prioritised report and free re-review
Every finding rated by severity with the exact policy or change to apply, and a free re-test once you have applied them.
How it works.
- 01
Access
You share the app's URL and read access to the Supabase project, or just the URL to start; the public surface alone reveals a lot.
- 02
Test
We test the live project from outside with the public key and two accounts, then review every table, policy and function by hand.
- 03
Report
You get a clear, prioritised write-up within days, with the correct policy written out for each gap, plus a call to walk through it.
- 04
Re-review
After you apply the policies and fixes, we re-run the same tests and confirm the project is closed.
Common questions.
- My anon key is public. Is that the problem?
- No. The anon or publishable key is meant to be shipped; it identifies your project and gets a request as far as the anon role. Row level security policies decide what that role can read and write, so the key is exactly as safe as your policies are. If every table has real policies, publishing it costs you nothing.
- The dashboard shows RLS enabled on every table. Am I safe?
- Not necessarily. A table with a policy of USING (true) is readable by anyone holding your public key while showing RLS as on, and a SECURITY DEFINER view bypasses policies entirely. Neither produces a warning. Whether the policies are correct for your data model is the actual question, and it is what this audit answers.
- What about the legacy key retirement?
- If your project predates November 2025 it runs the legacy anon and service_role keys, which are scheduled for deletion and, critically, can no longer be rotated. An exposed legacy service_role key stays exposed until you migrate to the new publishable and secret keys. We check your key status in every audit and plan the migration where it is needed.
- Can you fix the issues, not just find them?
- Yes. We can write and apply the policies, close the functions and buckets, run the key migration, or hand your team a precise prioritised list. Either way the free re-review confirms the project actually closed.
- How much does a Supabase security audit cost?
- It is scoped to a fixed quote up front, with no hourly meter, and typically starts around $750 depending on the size of the project. You will know the price before we begin.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.