Supabase: Row-Level Security (RLS) bypasses
Supabase exposes PostgreSQL directly via PostgREST APIs. Security is enforced using PostgreSQL Row-Level Security (RLS) policies. If RLS is disabled on a table, anyone with the public `anon` API key (which is bundled in your JavaScript app) can perform arbitrary select, insert, and delete operations on that table.
During a security audit, we check the RLS status of every table in the database:
-- Query to check RLS status on PostgreSQL tables
SELECT relname, relrowsecurity
FROM pg_class
WHERE relnamespace = 'public'::regnamespace AND relkind = 'r'; The Exploit: If a table has relrowsecurity = false, we use the `anon` key to query the API directly and extract the entire table contents:
# Extract table data using the public anon key
curl -H "apikey: SUPABASE_ANON_KEY" \
-H "Authorization: Bearer SUPABASE_ANON_KEY" \
https://your-project.supabase.co/rest/v1/user_profiles The Fix: Always enable RLS on every table. Write strict policies that bind actions to the authenticated user ID (auth.uid()):
-- SECURE RLS policy pattern
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Allow users to manage their own profile"
ON user_profiles
FOR ALL
USING (auth.uid() = user_id); Firebase: Permissive Firestore and Storage rules
Firebase applications write data directly to Cloud Firestore or Firebase Storage. Access control is defined in the `firestore.rules` file. A common configuration error is using weak rules templates meant for development:
// VULNERABLE Firestore Rules
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 8, 1); // Timeout bypass rule!
}
}
} The Fix: Block wildcard matches and define explicit collection paths with authenticated token validations:
// SECURE Firestore Rules pattern
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /user_wallets/{walletId} {
allow read, write: if request.auth != null && request.auth.uid == resource.data.userId;
}
}
} Auditing Service Role (Admin) key usage
BaaS architectures use administrative keys (like Supabase `service_role` key or Firebase Service Account json) to bypass security checks in backend scripts. If these keys are committed to frontend bundles or exposed via API routes, they grant full administrative control over the entire database. We review all client bundles and environment properties to verify that no service keys are exposed.
Disabled RLS leading to profile data dump
During an audit of a savings app built with Supabase, we extracted the public `anon` key from the React Native JavaScript bundle. By querying the REST API, we discovered that the user profiles table did not have RLS active. We downloaded 12,000 profile records including phone numbers and email addresses. Fix priority: critical. Remediated by enabling RLS and enforcing auth.uid() owner policies.
Building a serverless application with Supabase or Firebase? Schedule a security review.
Book a BaaS Security AuditFrequently asked questions
Why is a leaked anon key in Supabase not a vulnerability on its own?
Supabase anon keys are designed to be exposed to the client. The security of your database depends on PostgreSQL Row-Level Security (RLS) rules, not the secrecy of the anon key. If RLS is disabled or misconfigured, however, the anon key grants full read/write access to the database.
How do you audit Firestore security rules?
We audit Firestore rules by checking for wildcards that permit read/write access (e.g., `allow read, write: if true;`) and verifying that resource ownership checks are enforced on all document collections.
What is the security risk of Firebase Cloud Functions?
Firebase Cloud Functions are backend endpoints. If they fail to validate authenticated user contexts or accept parameters blindly, they are vulnerable to business logic bypasses and data leaks.
Related reading
Blog: Securing Firebase backends · React Native pentesting guide · API leaks
Services: API security testing · Secure architecture review