Supabase Security

Supabase tables without RLS enabled allow any authenticated or anonymous user to read, insert, update, and delete all rows using the client library.

RLS policies that use USING(true) or WITH CHECK(true) effectively disable row-level security by allowing all operations for all users.

RLS is enabled on a table but no policies are defined, which silently blocks all access including legitimate queries from your application.

The Supabase service_role key is hardcoded in frontend code, committed to a repository, or exposed in client bundles, granting full database admin access to anyone.

Supabase storage buckets with overly permissive policies allow any user to upload, read, or delete files including other users' private documents and images.

Supabase database functions (RPC) callable from the client without checking auth.uid(), allowing anonymous users to execute privileged operations.

The anon database role has been granted permissions on too many tables, expanding the attack surface for anyone with the publicly available anon key.

Database schema changes are applied manually through the Supabase Dashboard instead of tracked migration files, making security audits and rollbacks impossible.