SupaBased

SELECT * FROM users; anon_key=eyJhb; RLS disabled; service_role; INSERT INTO auth; DROP TABLE; pg_dump; .env.local; SUPABASE_KEY=; password123; secret_key; api_token

credentials_found; public.users; storage.objects; auth.users; phone_number; billing_info; session_token; jwt_secret; database_url; connection_string

ALTER TABLE DISABLE ROW LEVEL SECURITY; grant all on schema public; SUPABASE_ANON_KEY; create policy; auth.uid(); service_role_key

email password name address phone ssn dob credit_card api_key webhook_secret; rls_enabled=false; is_super_admin=true

SELECT * FROM auth.users; profiles; subscriptions; payments; documents; chat_messages; medical_records; student_data

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9; Bearer; x-api-key; authorization; supabase-url; anon-key

POST /rest/v1/users; GET /rest/v1/; DELETE /rest/v1/profiles; PATCH /rest/v1/auth; .select(*); .from(users)

Row Level Security is DISABLED for table; no policies found; public access granted; all operations permitted

password_hash; oauth_token; refresh_token; access_token; private_key; signing_secret; encryption_key; admin_password

CREATE POLICY ON public.users FOR ALL USING (true); rls_enabled: false; grant usage on schema public to anon

SELECT * FROM information_schema.tables WHERE table_schema='public'; pg_catalog; pg_tables; columns

user_metadata; app_metadata; raw_user_meta_data; email_confirmed_at; phone_confirmed_at; is_sso_user

supabase.co/rest/v1/; apikey=eyJ; Authorization: Bearer eyJ; content-type: application/json; Prefer: return=representation

CRITICAL: service_role key in client bundle; WARNING: RLS disabled on 47 tables; ALERT: PII exposed in public schema

storage.buckets; storage.objects; select * from storage.objects; public bucket; authenticated bucket; owner_id

// What is this

The Default Is Dangerous

Supabase tells developers the anon key is "safe to use in a browser." It is — if you configure Row Level Security. But after scanning over 5,000 sites, we can confirm: almost nobody does.

RLS is disabled by default. The REST API is enabled by default. The anon key is designed to be public. The result is a database that is wide open by default and secure only by opt-in.

Every Supabase project exposes a PostgREST API at a predictable URL. With the anon key — which is embedded in every frontend bundle — anyone can query every table in the public schema unless Row Level Security policies explicitly prevent it.

This is not a bug in Supabase's code. It is a systemic design flaw in how security is communicated, defaulted, and enforced. The documentation says "enable RLS." The dashboard warns you. But the path of least resistance — the one every tutorial follows, the one every hackathon project ships — is the insecure one.

// Am I affected

How to Know If You're Exposed

If you use Supabase and haven't explicitly enabled RLS on every table in your public schema, you are likely affected.

Is your anon key in your frontend JavaScript? It probably is -- that's by design. This is normal, but it means your RLS policies are the only thing between the public internet and your data.
Have you enabled RLS on every table? Check: Supabase Dashboard → Authentication → Policies. If any table shows "RLS disabled," you're exposed.
Is your service_role key only in server-side code? This key bypasses all RLS. If it's in a .env file that gets bundled into your frontend, anyone can read your entire database and modify any row.

Quick test: Open your browser DevTools, go to the Network tab, and look for requests to supabase.co/rest/v1/. The apikey parameter is your anon key. Now try:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/YOUR-TABLE?select=*" -H "apikey: YOUR-ANON-KEY" -H "Authorization: Bearer YOUR-ANON-KEY"

— if it returns data, RLS is not enabled on that table.

// Selected findings

What Exposure Looks Like

No companies are named. Disclosure is in progress. These are real findings from real production applications.

Critical 7 service_role keys found in client-side HTML — granting full database admin access, including the ability to read, write, and delete any row in any table, bypass all RLS policies, and access auth.users directly.

Critical A mental health platform: 91 tables exposed — including AI-generated therapy chat sessions, billing records, insurance information, and therapist notes. Full read access with the public anon key.

Critical An e-signature platform: access tokens exposed — allowing retrieval of signed documents, signer identities, and the ability to forge document completion status.

Critical A financial services company: DELETE access on the users table — any anonymous user could delete all customer accounts. No authentication required.

High A school system: plaintext passwords, phone numbers, PINs — student and parent contact information, login credentials stored in cleartext, and administrative access codes all readable via the public API.

// Recommendations

What Should Supabase Do

1 Enable RLS by default. Every new table should have Row Level Security enabled at creation. Developers who want to disable it can opt out explicitly. The current default puts every new developer one tutorial away from a data breach.
2 Detect service_role keys in browser contexts. If a service_role key is sent from a browser User-Agent or a non-server IP, flag it immediately. This is always a misconfiguration and should trigger an alert.
3 Add a security dashboard. Show developers a real-time view of which tables have RLS disabled, which have no policies, and which are accessible to the anon role. Make the insecure state visible and impossible to ignore.
4 Rate limit the OpenAPI spec endpoint. The /rest/v1/ endpoint returns a full schema description. This makes automated scanning trivial. Apply rate limiting and consider requiring authentication for schema introspection.