Get the access rules on your Supabase project right.

Common failure modes

These turn up in fast-built apps whatever they were built with, once an app grows faster than anyone reviews it. Most can be fixed where the app is.

1. Tables without row-level security

   The anon key ships to every browser by design. For any table in an exposed schema without row-level security, that key is enough to read it, and sometimes to change it.

   Apps built with Lovable on Supabase have shipped with row-level security missing, recorded as CVE-2025-48757. Wikipedia: Lovable (company)

2. The wrong key in the front end

   The service-role key bypasses row-level security entirely. It belongs on a server or in an edge function, never in a browser bundle, a mobile app or a public repository.

   Moltbook leaked 1.5 million API tokens through a Supabase key in its front end. Wikipedia: Moltbook

3. Policies that are too broad

   A policy that is simply true, or one that allows any authenticated user, protects nothing between your users. A policy that compares against a column users can set themselves can be walked around.

4. Storage and functions

   Public storage buckets, long-lived signed URLs, and database functions that run with more rights than their caller can all reach data the table policies were meant to protect.

5. Auth settings

   Open sign-up on an app meant for invited users, email confirmation turned off, or redirect URLs that allow any site.

What the audit checks on a Supabase app

The code and product audit reads the code, not only what is visible from outside, and ranks every finding by what it means for the business. On a Supabase app, that includes:

• Every table, view and function exposed through the API, and the policy that guards it, checked against who should see what.
• Which keys ship where: the anon key in the browser, and the service-role key nowhere it can leak.
• Storage bucket policies and signed URL lifetimes.
• Auth configuration: sign-up, confirmation, password reset, redirect URLs and providers.
• Edge functions and their secrets.
• Migrations, environments and backups: how the schema changes, and how it would be restored.
• Your product and business goals, from an interview, so every finding is ranked by what it means for the business.

Production-ready where you are

The default recommendation is to tighten the project you have. Moving to a different database is recommended only when the audit shows it is worth the cost.

Run the free check on your Supabase app.

It scans what your app already shows the world, such as keys in its JavaScript, its headers, HTTPS and versions, and Aaron reviews the result within two business days. It runs only after you confirm by email and show the app is yours.