Firebase Security Checklist: Protect Your AI-Built App

Quick answer: Review Firebase Security Rules, authentication, function authorization, and API-key scope before launch. Test the access each role needs, including anonymous requests. Evaluate App Check separately as an abuse-reduction layer; neither a deadline nor a configuration checklist establishes production safety.

By Gabriel CA · Kraftwire Software

Review Firebase Security Rules, authentication, function authorization, and API-key scope before launch. Test the access each role needs, including anonymous requests. Evaluate App Check separately as an abuse-reduction layer; neither a deadline nor a configuration checklist establishes production safety.

What Should You Lock Down Before Launching a Firebase App?

Review Security Rules for each database or storage service, API-key restrictions, and Authentication settings against the application’s requirements.

Apply the same review to apps built with Lovable, Bolt.new, Cursor, or other tools.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

Test the relevant configuration and access paths directly; the aggregate corpus does not establish which Firebase rules caused a finding.

Why Does Firebase Security Matter for AI-Built Apps?

Inspect the deployed rules rather than assuming a particular test-mode duration. A time-based allow condition stops granting access after its deadline; other matching allow rules can still grant access. The deadline does not rewrite the rules into a production policy.

Firebase web configuration is intended to be usable by client applications. Its API key identifies the project; it does not authorize database access. Review Security Rules and applicable IAM controls instead of relying on configuration secrecy.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

Test anonymous, authenticated-owner, and other-user access according to the application’s permissions. Review any broad allow grants, including allow read, write: if true; a controlled curl request can test a specific anonymous HTTP access path.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

Review schema and operational requirements directly; the architecture statistic does not assess this project’s database resilience.

How Do You Write Secure Firestore Rules?

Firestore Security Rules authorize requests made through covered client access paths. They are not result filters: a query must meet the rules for its potential results. Server libraries using privileged credentials use IAM instead, so review those access paths separately.

A Broad Time-Limited Allow Rule

This illustrative rule permits unauthenticated client access before the date in its condition:

Before the displayed deadline, this rule permits reads and writes across matched documents without authentication. That historical deadline has passed. With this rule alone, client requests no longer satisfy the condition; with additional rules, any matching allow condition can still authorize access.

Review an Incomplete Authorization Example

The following example uses identity checks through request.auth, but it is not ready to deploy. Profile creation is not restricted to the matching user ID, profile fields are unrestricted, and post creation does not bind the author field to the caller. Updates also need to prevent unauthorized ownership changes. The broad false rule does not override a matching true rule. Add and test the required ownership and field constraints before using this structure.

Rule Writing Checks

• Default Denial: Unmatched requests are denied. allow read, write: if false; does not override another matching grant.
• Data Validation: Validate request.resource.data, including allowed fields, types such as price, and immutable ownership fields.
• Recursive Scope: Review the paths matched by {document=**}; broad grants can reach subcollections, while a false condition grants nothing.
• Testing: Test allowed and denied cases with the Firebase Emulator Suite before deployment.

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.

Overbroad RTDB Example

While this requires a login, it allows any logged-in user to read or delete any other user's data. This is a classic broken access control vulnerability.

Owner-Path RTDB Example

This example scopes access by user path; add data validation and test any broader grants in the complete ruleset. See the database security scanner guide.

How Do You Lock Down Firebase Storage Rules?

Review Storage read and write permissions, object sizes, and usage controls. Permitted uploads can consume storage and transfer resources; that is separate from bucket-name ownership.

Critical Storage Checks

Auth Check

Ensure request.auth != null for all uploads.

Size Limits

Set per-object size limits appropriate to the application; these do not cap total storage or spending.

Content Type

Restrict declared MIME types such as image/png, then validate file contents where required. Metadata alone does not establish that bytes match the declared type.

The following illustration allows any authenticated user to read matching objects. Its write condition checks the owner path, a per-object size threshold, and declared image MIME type; it does not verify image bytes or limit total usage. Deletion needs a separate policy because there is no new upload resource to validate. Adapt and test these behaviors before deployment.

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

Review localhost, firebaseapp.com subdomains, and any other entries against the intended sign-in flows. Keep only needed domains and use a separate development project where appropriate. The authorized-domain list is not a replacement for user authentication or database authorization.

Disable Unused Providers

Enable only the sign-in providers the application requires and test registration, recovery, and account-linking flows.

Multi-Factor Authentication (MFA)

Choose supported authentication factors appropriate to the application and enforce the required assurance at sensitive operations. Enrollment alone does not establish enforcement.

How Do You Secure Firebase Cloud Functions?

Keep secret credentials server-side and inspect client bundles and repositories for exposure.

Authentication in Functions

For protected callable functions, verify the auth context in onCall requests and then authorize the operation. This example shows only an authentication guard; payment input validation and authorization still need implementation.

Environment Variables and Secrets

Do not hardcode API keys for Stripe or OpenAI 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?

The Firebase client API key in firebaseConfig identifies the project; it is not a secret database-access credential. Review API restrictions for the services the application needs, and use separate credentials for unrelated Google Cloud APIs.

Google Cloud Console Review

Inspect the key’s API allowlist and any application restrictions supported by the actual clients and APIs. For browser restrictions, a pattern such as https://myapp.com/* must match the intended workflow; it does not replace Security Rules or user authorization. Test changes so required authentication calls continue to work.

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

Advanced Protection: Firebase App Check

App Check evaluates attestation through the configured provider and can reject requests without accepted tokens when enforcement is enabled for a supported service. It does not establish that every accepted request is benign.

Test App Check alongside user authorization, input handling, and usage limits. An accepted token does not guarantee a legitimate action or prevent every attempt to consume AI API resources.

Firebase Configuration Review Checklist

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

Production Rules

Review broad grants such as allow if true and time-based rules; public access should be deliberate and limited to intended resources.

Auth-Locked Storage

Protected upload paths check the intended request.auth.uid ownership and required permissions.

File Validation

Storage contentType and size checks reviewed alongside file-content validation and aggregate usage controls.

Application Restrictions

Supported API-key application restrictions tested against the clients that need access.

API Scoping

API keys restricted to only necessary services (Firestore, Auth).

Authorized Domains

localhost and staging-domain entries retained only where needed by the intended sign-in workflow.

Provider Cleanup

Unused auth methods (Anonymous, Phone, etc.) disabled.

Function Auth

Protected onCall and onRequest operations authenticate callers appropriately and enforce authorization; HTTP handlers need their own verification logic.

Secret Management

No hardcoded keys in Cloud Functions; use Secret Manager.

App Check

App Check enforcement evaluated and tested for supported services; authorization remains separate.

Billing Alerts

Usage and billing alerts configured and tested. Alerts do not impose a hard spending cap.

Audit Logging

Supported audit logging enabled for required events, with access controls, retention, and sensitive-data handling reviewed.

How Do You Test Your Configuration?

Use complementary methods to test configuration:

• Rules Tests: Test specific paths, operations, and identities with the Rules Playground or Emulator Suite.
• Unit Testing: Use @firebase/rules-unit-testing for automated allowed and denied cases.
• URL Scanning: SimplyScan reports supported public findings, including detectable secret exposure and anonymously readable sensitive backend data. It does not inspect every rule or verify authenticated cross-user access.

The Bottom Line

Review database rules and authentication separately from how quickly the application was built.

The average security score across the 119 live sites SimplyScan has scanned is 86 out of 100.

The aggregate score does not identify Firebase configuration defects in a particular application.

Review and test the configuration against the application’s requirements. The required effort depends on scope; completing a quick pass does not establish safety. See the security checklist guide.

FAQ

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

Firebase client API keys identify the project and are designed for client use; they do not authorize database access. Review Security Rules, IAM where applicable, and appropriate key restrictions. Billing alerts report usage but do not cap spending.

What happens when a time-limited Firestore rule expires?

The time condition stops granting access after its deadline. Other matching allow rules may still authorize requests, so inspect the complete ruleset. Do not reopen private data with allow read, write: if true; test the access each role actually needs.

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

Review deployed rules and test anonymous access to the relevant paths, including grants such as allow read, write: if true or .read: true. Use controlled tests and the Emulator Suite. SimplyScan can report supported anonymously observable exposure, but a clean URL scan does not establish that every path is private.

What is Firebase App Check and do I need it?

App Check uses provider attestation and, when enforcement is enabled for supported services, rejects requests lacking accepted tokens. It complements Security Rules and user authorization. Accepted requests can still be abusive, so review operation permissions and usage controls separately.

How long does it take to secure a Firebase app?

The effort depends on the application’s data, rules, functions, and test coverage. Work through the relevant controls and verify allowed and denied behavior. A fixed time estimate or completed checklist does not establish security.

How should I review Firebase authorized domains?

Review the domains needed for the application’s sign-in flows and remove unnecessary entries. Use appropriate separation between development and production. Domain settings do not replace user authentication, application authorization, or database rules.