My Supabase database might be public — how do I check?

Eleven percent of AI-built apps have at least one public Supabase table. Check yours in 30 seconds.

You read a Wiz blog about Moltbook leaking 1.5 million API keys through a Supabase misconfiguration. You realize you don't actually know if your Supabase has the same bug. You've never heard of Row-Level Security. You don't even know where to start.

What happens next

  1. If your tables are public

    Anyone with your Supabase URL and anon key (both public by design — they ship in your app's JavaScript) can read every row in every exposed table.

  2. How attackers find you

    Automated tools scrape public GitHub repos, search JavaScript bundles on live sites, and enumerate Supabase projects. If your app is live, they've already probed it.

  3. What they do with the data

    Exfiltrate everything. Customer records, email addresses, credit-card last-4s, private messages, internal notes. It ends up in data-dump markets within days.

Without Securie

You either don't know about the bug at all, or you manually enable RLS on every table and write policies yourself — which requires understanding Postgres RLS syntax, tenant scoping, and security-model design.

With Securie

Run the free scanner at /signup. Paste your project URL and anon key; the scan runs in your browser in 30 seconds. If tables are exposed, Securie generates the exact SQL to paste into the Supabase SQL editor.

Exactly what to do right now

  1. Open /signup
  2. Paste your Supabase project URL + anon key (never service-role key)
  3. Read the scan results — red dots = exposed, green = protected
  4. For each red-dot table, paste the generated SQL into Supabase → SQL Editor
  5. Rerun the scan to confirm every table is green
  6. Install Securie on your GitHub repo so future tables get this check automatically