Row Level Security disabled
Without RLS policies, the anon key can SELECT, INSERT, UPDATE, and DELETE on your tables. We probe the usual suspects and flag any table that returns data to an unauthenticated request.
// Supabase security
Your Supabase anon key is public. Is your data? check free.
The anon key is meant to be public — Supabase's whole security model rests on Row Level Security doing the gatekeeping instead. If RLS is off, that public key reads your entire database.
Scan your Supabase app now — free, ~60 seconds, no signup.
Supabase gives every project a public anon key for browser access and a secret service_role key that bypasses all security. The anon key being in your front-end is normal and expected — Row Level Security (RLS) is what's supposed to stop it from reading data it shouldn't.
In vibe-coded apps, RLS is the step that gets skipped. The app works perfectly in testing because the developer is the only user — then at scale, anyone can lift the anon key from the network tab and query every table directly.
11%
of vibe-coded apps leak a usable Supabase key
SupaExplorer, 20,000 URLs scanned
CVE-2025-48757
the named vulnerability class for missing Supabase RLS
Disclosed 2025
2,000+
critical vulns found across 5,600+ AI-built apps audited
Escape.tech
What goes wrong on Supabase
service_role key in the client
The service_role key ignores RLS completely. If it ever ends up in front-end code or an exposed env file, your database is fully open. We scan bundles and common file paths for it.
Public storage buckets
Buckets set to public expose every uploaded file by URL. Combined with predictable paths, that's a direct route to user documents and images.
Over-permissive policies
Even with RLS on, a policy like `using (true)` defeats the point. Policies should scope rows to the authenticated user (`auth.uid() = user_id`).
Your Supabase security checklist
- RLS enabled on every table in the public schema
- Policies scope rows to the authenticated user — no `using (true)`
- service_role key never leaves your server / secrets store
- Storage buckets private by default, signed URLs for access
- Realtime and Edge Functions respect the same auth rules
- Anon key rotated if it was ever paired with open tables
Supabase security FAQ
Is it safe to expose the Supabase anon key?
Yes — as long as Row Level Security is enabled and your policies are correct. The anon key is designed to be public. It only becomes dangerous when RLS is off, which lets it read data freely.
How do I know if my RLS is set up right?
The fastest check is to query your tables with just the anon key, the way an attacker would. bleek's free scan does exactly that and tells you which tables are exposed.
What's the difference between anon and service_role keys?
The anon key respects RLS; the service_role key bypasses it entirely. The service_role key must never appear in client code or public files — treat it like a database admin password.
Find your Supabase app's leaks now.
Free scan, real findings, a copy-paste fix for each one. No signup.