Firebase Security Checklist: Protect Your AI-Built App

Quick answer: Firebase defaults are permissive: Realtime Database and Firestore often start in "test mode," leaving data open to anyone. To secure your app, you must implement deny-by-default security rules, restrict API keys by HTTP referrer, and enable App Check to block unauthorized bot traffic and scripts.

By Gabriel CA · Kraftwire Software

To secure a Firebase app before launch, you must replace "test mode" rules with granular production rules, restrict API keys by HTTP referrer in the Google Cloud Console, and enable Firebase App Check to block unauthorized clients.

What Should You Lock Down Before Launching a Firebase App?

Firebase provides a robust backend-as-a-service (BaaS) environment, but its "vibe-friendly" onboarding often leads to dangerous security gaps. The most critical items to lock down are your Security Rules (Firestore, Realtime Database, and Storage), API Key restrictions, and Authentication settings.

If you are building with tools like Lovable, Bolt.new, or Cursor, the AI may generate functional code that ignores security best practices. According to recent industry data, the single most common Firebase security failure in production is shipping with the default test-mode rules: allow read, write: if true. This effectively makes your entire database public to anyone with your project ID.

Why Does Firebase Security Matter for AI-Built Apps?

AI-built or "vibe-coded" applications are particularly susceptible to Firebase misconfigurations. When an LLM generates a Firebase integration, it often prioritizes "making it work" over "making it secure."

These often include exposed configuration files or open database nodes. Because Firebase uses a client-side SDK, your project configuration (including your API key) is inherently public. Without strict server-side rules, there is no "secret" barrier protecting your data.

How Do You Write Secure Firestore Rules?

Firestore security rules are your primary defense. They are not just filters; they are the authorization layer that sits between the internet and your data.

The Most Dangerous Rule

Many developers leave their rules in "Test Mode," which looks like this:

This allows anyone to read, modify, or delete any document in your database until the expiration date. If your app is vibe-coded, the AI might not prompt you to change this before you deploy to a production URL.

How to Fix It: Granular Authorization

You must define rules based on the user's identity (request.auth). A secure pattern ensures users can only touch what they own.

Rule Writing Best Practices

• Deny by Default: Start with allow read, write: if false; at the root and open specific paths.
• Validate Data: Use request.resource.data to ensure incoming data matches your schema.
• Avoid Recursive Wildcards: Using {document=**} in an allow statement is dangerous as it applies to all subcollections.
• Use the Emulator: Test your rules locally using the Firebase Emulator Suite before deploying.

How Do You Secure Realtime Database Rules?

The Realtime Database (RTDB) uses a JSON structure for rules. Unlike Firestore, RTDB rules "cascade" · if you grant .read at a parent node, the user has read access to every child node regardless of deeper rules.

Dangerous Default

While this requires a login, it allows *any* logged-in user to read or delete *any* other user's data.

Secure RTDB Pattern

For more on database hardening, see our database security scanner guide.

How Do You Lock Down Firebase Storage Rules?

Firebase Storage is often overlooked, leading to "bucket squatting" or quota exhaustion attacks where malicious actors upload gigabytes of data to your account.

Critical Storage Checks

• Auth Check: Ensure request.auth != null for all uploads.
• Size Limits: Prevent massive file uploads that could spike your bill.
• Content Type: Only allow specific MIME types (e.g., image/png).

How Should You Configure Firebase Authentication?

Authentication is the gateway to your app. Misconfiguring it can lead to account takeovers or bot registrations.

Authorized Domains

By default, Firebase adds localhost and firebaseapp.com subdomains to your authorized list. Remove localhost from your production project settings. If an attacker hosts a malicious script on their own localhost, they could potentially trigger auth flows against your project.

Disable Unused Providers

If you only use Google Login, disable Email/Password and Anonymous auth. Each enabled provider is a potential entry point for attackers to probe for broken access control.

Multi-Factor Authentication (MFA)

For apps handling sensitive data, enable MFA. While Firebase supports SMS MFA, be aware of its limitations and consider it a baseline rather than a total solution.

How Do You Secure Firebase Cloud Functions?

Cloud Functions act as your backend logic.

Authentication in Functions

Never assume a function is secure just because the URL is "hidden." Always verify the auth context in onCall functions:

Environment Variables and Secrets

Do not hardcode API keys for Stripe, OpenAI, or Anthropic in your function code. Use the Google Cloud Secret Manager integration or firebase functions:secrets:set. For more on this, read our guide on how to remove secrets from git history.

How Do You Restrict Firebase API Keys?

A common misconception is that the Firebase API key (found in firebaseConfig) must be kept secret. It is actually public by design. However, it must be restricted.

Google Cloud Console Hardening

Navigate to the Google Cloud Console (APIs & Services > Credentials) and find your "Browser key."

• HTTP Referrer Restriction: Add your production domain (e.g., https://myapp.com/*). This prevents other websites from using your key to consume your Firebase quota.
• API Restrictions: Limit the key so it can only call Firebase-related APIs (Firestore, Auth, etc.) and not other Google Cloud services.

For a deeper dive into why these keys are public, see API keys in frontend.

Advanced Protection: Firebase App Check

App Check is a powerful layer that protects your backend resources from abuse. It ensures that traffic is coming from your actual app (verified via Play Integrity, App Attest, or reCAPTCHA Enterprise) and not from a bot or a curl script.

Many of these could be mitigated by implementing App Check to enforce "provenance" · proving the request originated from your legitimate frontend.

The Ultimate Firebase Security Checklist

Before you hit "deploy" on your Windsurf or v0 project, verify these 12 points:

• Production Rules: No allow if true or expired test-mode rules in Firestore or RTDB.
• Auth-Locked Storage: All storage uploads require request.auth.uid matching the path.
• File Validation: Storage rules enforce contentType and size limits.
• Referrer Restrictions: API keys restricted to your production domain in Google Cloud Console.
• API Scoping: API keys restricted to only necessary services (Firestore, Auth).
• Authorized Domains: localhost and unused staging URLs removed from Auth settings.
• Provider Cleanup: Unused auth methods (Anonymous, Phone, etc.) disabled.
• Function Auth: All onCall or onRequest functions verify the user's identity.
• Secret Management: No hardcoded keys in Cloud Functions; use Secret Manager.
• App Check: Enabled for Firestore and Functions to block non-app traffic.
• Billing Alerts: Set up in Google Cloud to catch unexpected usage spikes.
• Audit Logging: Data Access audit logs enabled for sensitive collections.

How Do You Test Your Configuration?

You cannot secure what you do not measure. Use these three methods to validate your Firebase app:

• Firebase Rules Playground: Use the built-in simulator in the Firebase Console to test specific paths against specific UIDs.
• Unit Testing: Use the @firebase/rules-unit-testing library to write automated tests that run in your CI/CD pipeline.
• Automated Scanning: Use SimplyScan to run a 30-second health check. Our scanner detects exposed API keys, missing security headers, and common Firebase misconfigurations that AI tools often overlook.

The Bottom Line

Firebase makes it incredibly easy to build fast, but that speed often comes at the cost of security.

Spend the extra hour to lock down your rules and restrict your keys. It is the difference between a successful launch and a security advisory. For more tips on securing AI-generated code, check out our vibe coding security checklist guide.

FAQ

Is it safe that my Firebase API key is visible in my frontend code?

Yes, Firebase web API keys are designed to be public; they identify your project rather than authenticate access. Real protection comes from your security rules. Still, restrict the key in Google Cloud Console by HTTP referrer and by API scope, use separate keys for development and production, and set billing alerts so abuse cannot generate runaway charges.

What happens when Firestore test mode expires after 30 days?

Test mode rules include an expiry date, and once it passes Firestore starts denying client requests, which usually surfaces as your app suddenly failing to read or write data. Do not respond by re-opening access with allow read, write: if true. Replace test mode with production rules that deny by default and grant specific, authenticated access per collection.

How can I tell if my Firebase database is publicly exposed?

Check whether your Firestore or Realtime Database rules allow access without authentication, for example allow read, write: if true or .read: true at the root. Automated scanners constantly probe Firebase projects for open rules, so assume an open database will be found. Test with the Rules Playground, the Emulator Suite, and a third-party scan of your deployed app such as SimplyScan.

What is Firebase App Check and do I need it?

App Check verifies that requests to Firestore, Realtime Database, Storage, and Cloud Functions come from your legitimate app rather than scripts or modified clients. It complements security rules rather than replacing them: rules decide who may access data, App Check filters out illegitimate clients. Enabling it is recommended for all production Firebase apps and belongs on any pre-launch checklist.

How long does it take to secure a Firebase app?

About an hour for the core pass. Working through the checklist covers replacing test-mode rules, restricting Storage uploads, trimming authorized domains, disabling unused auth providers, verifying Cloud Function auth checks, restricting API keys, and enabling App Check. For a typical app that is an afternoon at most, and it is far cheaper than dealing with a data breach afterwards.

Why should I remove localhost from Firebase authorized domains?

During development Firebase accepts authentication from any listed domain, and localhost plus test domains often linger into production. If your project accepts auth from domains you do not control, an attacker can host a phishing page that harvests credentials valid against your real app. Before going live, restrict the authorized domains list in Authentication settings to your actual production domains only.