Documented behaviour side by side
| Aspect | Supabase | Firebase |
|---|---|---|
| Access control mechanism | Postgres Row Level Security. Policies are SQL expressions attached to tables. | Firebase Security Rules, a declarative rules language, for Cloud Firestore, Realtime Database and Cloud Storage. |
| Public client key | The publishable key (and the legacy anon key) is documented as safe to expose. It maps to the anon role, or the authenticated role once a user signs in. | Firebase API keys identify your project and app. The docs say data security is enforced by Security Rules, not by keeping the API key secret. |
| Privileged server credential | The secret key (and the legacy service_role key) maps to a role with the BYPASSRLS attribute and skips every policy. | The docs say the server client libraries bypass all Cloud Firestore Security Rules and authenticate through Google Application Default Credentials, governed by IAM. |
| What the docs tell you to enable | Enable RLS on every table in an exposed schema. Once RLS is on, the publishable key reaches no data until you create policies. | Configure rules before deploying. New databases and buckets offer a locked mode that denies all access and a test mode that grants access to all users. |
| Documented insecure patterns | A policy of using (true) grants every visitor read access to every row the role can reach. Views bypass RLS by default unless configured otherwise. | Open access rules, rules that allow any authenticated user, and improperly inherited Realtime Database rules. |
| Tying rules to the signed-in user | auth.uid() returns the id of the user making the request and returns null when there is no authenticated user. | Rules can use Firebase Authentication data to grant user-based permissions. |
| Extra client attestation | Confirm current options in the vendor's documentation. | Firebase App Check is documented as controlling which apps can access your resources. |
What Supabase leaves to you
- Enabling Row Level Security on every table in an exposed schema, including tables created later by an AI assistant or a migration.
- Writing a policy for each operation. A select policy does not cover insert, update or delete.
- Avoiding using (true) on anything that is not meant to be public.
- Checking views, since the docs say views bypass RLS by default.
- Keeping the secret or service_role key on the server only. It skips every policy by design.
- Moving off the legacy anon and service_role keys. The docs state they are being deprecated by the end of 2026.
What Firebase leaves to you
- Replacing test mode rules before launch. Firebase's docs warn that without authentication and rules, anyone who guesses your project id can read, change or delete data.
- Going beyond auth != null. The docs ask you to confirm that you really want any logged-in user to have access.
- Writing rules separately for each product you use: Firestore, Realtime Database and Cloud Storage each have their own.
- Applying API restrictions to your API keys, which the docs call critical.
- Treating server code with the Admin SDK as fully trusted. It bypasses rules, so your own code must check who the caller is.
The same mistake on both platforms
The common failure is identical: the app works in testing because rules are open, and nobody closes them. On Supabase that is a table without RLS or a policy that is always true. On Firebase it is test mode or a rule that allows every signed-in user.
A second shared mistake is putting the privileged credential in client code. On either platform that credential ignores your rules, so anyone who extracts it from the bundle has full access.
What to check whichever you pick
- A logged-out request with only the public key or config returns no private data.
- A second test account cannot read or change the first account's records.
- No rule or policy grants access to every authenticated user unless that is the intended design.
- File storage has its own rules, and private files are not reachable by URL when logged out.
- The privileged server credential does not appear in the built JavaScript, the mobile bundle or git history.
- Server functions that use the privileged credential verify the caller themselves.
- Rules and policies live in version control and are reviewed like code.
Frequently asked questions
Is Supabase more secure than Firebase?
Neither vendor's documentation supports that claim. Both expose a public client key and protect data with rules you write. The outcome depends on whether those rules are enabled, specific to each user and tested.
Is it safe to expose my Firebase API key?
Firebase's docs say API keys for Firebase services only identify your project and app, and that data is protected by Security Rules, not by keeping the key secret. They also say applying API restrictions to your keys is critical.
Is it safe to expose my Supabase anon key?
Supabase documents the publishable key, and the legacy anon key, as safe to expose. That holds only when Row Level Security is enabled with correct policies, because the key can reach whatever the anon and authenticated roles are allowed to reach.
What is the Firebase equivalent of Row Level Security?
Firebase Security Rules. They play the same role as Supabase RLS policies: they run on the vendor's servers and decide whether a client request may read or write a given path or document.