criticalexposurepublic probe
Table readable with the anon key
ANON_TABLE_READABLEThis table returned rows to an unauthenticated request carrying only the public anon key. Anything visible here is visible to the internet.
What the finding looks like
criticalTable "invoices" returned 1,247 rows to the public anon key
How to fix it
The public probe knows the table is readable but not why, because it cannot see your policies. Enable and force RLS, then connect the project for policy suggestions generated from the real column names.
Related guides
- RLS disabled on a public table: the most common Supabase leak
- The Supabase security gaps Lovable apps ship with
- World-readable tables in a Lovable build — and the one request that proves it
- Replit frontends and everything the anon key can reach
- Internal tools pointed straight at PostgREST
- Anyone can list my users table
- My API returns data with no login at all
- Your internal tool is reachable by the whole internet
- Can tenant A read tenant B? A test you can run tonight
- Probe your live app: what its own public key gives away
- Testing RLS as the anon caller, not as the admin
- Check whether your Lovable app is leaking data
What people search for
supabase anon key full table accesssupabase data leaklovable app leaking supabase data
Check your own project
This rule runs on the free probe. A URL is the only input.
Run the free audit