Supabase RLS Exposure Checker

Paste your Supabase project URL and anon key. This reads the project's own public schema listing to find every table the anon key can see, then sends one capped, read-only request per table and names which ones return real rows to an unauthenticated request — the missing-Row Level Security (RLS) exposure behind CVE-2025-48757 and the 170+ affected apps in 2025. Only run this against a project you own or are authorised to test.

Run the check

Enter your project URL and anon key, then click Check.

Prefer a CLI for CI?

Same check, same modules, no browser:

node check.mjs https://abcdefghijklmno.supabase.co eyJhbGciOi... --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — exit code 1 if any table is exposed, so you can gate a deploy on it. Run it after every migration that adds a table: RLS off is the default for a brand-new table on projects created before Supabase changed that default in 2026, and it takes exactly one forgotten table to reopen this.

Common questions

Isn't the Supabase anon key supposed to be public?

Yes -- Supabase's own model treats the anon key as safe to embed in client-side code, and it appears in the JavaScript bundle of every app that uses the project. What is not supposed to be public is your actual table data. Row Level Security (RLS) is the only thing standing between that public key and your rows: the anon role's default schema USAGE grant already lets it see the schema, so a table with RLS off (or a policy broader than intended) is readable by anyone who has ever loaded your app and opened the network tab.

What actually happened in CVE-2025-48757?

A vulnerability class affecting apps built with AI app-builder platforms (Lovable was the most widely reported) where generated Supabase tables were left without RLS enabled. Security researchers found 170+ applications and 303+ endpoints where the public anon key could read, and in some cases write, every row in tables that were never meant to be public -- including, in at least one 2026 incident, admin emails and internal schema metadata. More background: why disabling RLS exposes your data.

Is it safe to paste my anon key into this page?

The anon key is designed to be public -- it is already in your app's client-side bundle. This page never sends it (or your project URL, or anything it reads back) to our servers: every request goes straight from your browser to your own project's REST endpoint, the same way your app's own client already talks to it. Still, only run this against a project you own or are authorised to test.

How is this different from Supabase's own dashboard Security Advisor?

The dashboard Advisor lints your database configuration and needs you to be logged in as a project member. This tool checks the live REST API from the outside using only the anon key, the same view an attacker, an external auditor, or a developer without dashboard access would have -- useful when you've inherited a project, are auditing someone else's app with permission, or want a check that needs no login at all. See the full comparison against checking RLS in the dashboard by hand, or how this compares to a third-party scanner service.

Does a clean report mean my project is secure?

No. This checks one specific, well-documented exposure -- can the anon key read real rows from a table -- using a capped, read-only request per table. It does not test authenticated roles, storage buckets, Edge Functions, write/update/delete access, or anything past what the anon key's schema listing reveals. Treat a clean report as evidence about this one exposure, not a full security audit.