Why Is Google Firebase Still Sending Me Alerts About Insecure Data?

A Firebase security email can be confusing when you are building a public website. Your pages are supposed to be visible. Visitors need to read your articles, product descriptions, or event listings. So why is Google warning you that your data is insecure, and why does the warning keep coming back?

The important distinction is between making selected content public and leaving a database open. A website can be public without allowing strangers to read every record, change your content, or delete your data.

This guide reflects Firebase as of 2020; tools, interfaces, and alert behavior may have changed since then.

Firebase warnings deserve investigation, not automatic dismissal. Below, we will separate intentional public access from dangerous permissions, identify which rules matter, and walk through a safer Cloud Firestore configuration.

What an insecure-data alert actually tells you

Firebase Security Rules determine which requests made through Firebase client SDKs are allowed to access your data. Rules can permit or deny reads and writes based on the requested path, authentication, existing data, and proposed changes.

An insecure-rules warning indicates that Firebase has identified a potentially unsafe configuration. The exact meaning depends on the product and the notification. Common situations include broadly accessible data or permissive rules originally installed for development.

For Cloud Firestore, this is an obviously dangerous configuration:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

It allows anyone who can reach the database through the client API to read and modify documents. They do not need to use your website or its interface.

Removing an edit button does not fix this. Hiding your Firebase configuration does not fix it either. Firebase web configuration is normally delivered to the browser; your authorization boundary must be enforced by rules or a trusted backend.

Public reads and public writes are different risks

Public read access may be appropriate for published content. Public write access is usually not appropriate for a content-driven website.

However, public reads are not automatically harmless. They can expose drafts, customer details, internal notes, or other records that your interface never displays. Unrestricted reads may also enable scraping and unwanted usage costs.

The right question is not simply, “Is this website public?” It is:

Which documents should an anonymous person be able to read, and who should be able to create, change, or delete them?

Why the alerts may keep arriving

A recurring warning is a reason to verify the active configuration. It is not proof that Firebase has misunderstood your website.

You changed the wrong rules

Cloud Firestore, Realtime Database, and Cloud Storage for Firebase have separate rules. Updating Firestore does not secure a Realtime Database instance or files stored in a Storage bucket.

Likewise, changing a development project does not change production. Check the project and resource identified in the email against the ones your application actually uses.

Your changes were never published

Editing a local rules file does not update deployed permissions. A console edit must be published; a local edit must be deployed to the intended Firebase project.

A successful application deployment also does not necessarily mean your database rules were deployed.

A broad permission still overrides your intended restriction

Firestore rules are additive: if any matching rule allows a request, another matching rule cannot deny it.

For example, adding a restrictive rule for /users/{userId} does not protect those documents if a recursive wildcard elsewhere still grants everyone read and write access.

Development rules are still active, or are about to expire

Firestore test-mode rules commonly use a time-limited permission. Before the deadline, they can allow overly broad access; after the deadline, client requests can fail.

Extending that deadline keeps development moving but does not establish a production security policy. Read the notification carefully to distinguish an insecure-access warning from an upcoming rules expiration.

Finally, alert delivery and configuration checks need not reflect a change instantly. Verify deployed rules and actual access rather than repeatedly changing settings just to make an email disappear.

First, identify what Firebase is storing

A database does not necessarily contain everything on your website. A typical Firebase application may use:

• Firebase Hosting for HTML, JavaScript, CSS, and other deployed assets.
• Cloud Firestore for documents such as posts, profiles, and application records.
• Realtime Database for a separate JSON data tree.
• Cloud Storage for Firebase for uploaded images, PDFs, and other files.

A Firestore document might contain an image URL, while the image itself lives in Storage. A spreadsheet might be a Storage object, an external link, or data represented as database records. Each arrangement has different access controls.

Before changing rules, inventory the relevant resources. Protecting one layer does not automatically protect the others.

How to secure a public Firestore website

The following example assumes a website with public articles and a trusted publishing process. Readers do not need accounts, but browsers should not be allowed to modify published content.

1. Classify your documents

Write down the intended permissions before writing rules:

| Data | Anonymous access | Client writes | | --- | --- | --- | | Published articles | Read | None | | Draft articles | None | Authorized editors only, if supported | | User profiles | Owner-only read | Owner-only, validated updates | | Internal settings | None | None |

This simple exercise often reveals the real problem: public and private data are mixed together without a clear boundary.

Firestore reads return whole documents. Rules cannot reveal a title while hiding an internal note in the same document. Put information requiring different read permissions in separate documents.

2. Remove blanket permissions

Start from a policy that grants only the access your application requires. For a site whose /publishedArticles collection contains exclusively public information, a minimal ruleset is:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /publishedArticles/{articleId} {
      allow read: if true;
      allow write: if false;
    }
  }
}

With no other allow rules, unmatched document paths are denied. Anonymous visitors can read the published articles, but client applications cannot create, update, or delete them.

This rule does not automatically grant access to subcollections beneath each article. Add explicit permissions if your data model requires them.

Important: this example assumes you publish through a trusted server process. Firestore server libraries and the Admin SDK use IAM rather than client Security Rules. Secure their credentials and validate any backend endpoint that writes on a user's behalf.

3. Keep drafts out of public results

If you keep drafts and published articles in one collection, you can make access conditional:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /articles/{articleId} {
      allow read: if resource.data.published == true;
      allow write: if false;
    }
  }
}

This is an alternative to the previous collection layout, not an extra rule that restricts an existing blanket allowance.

Firestore rules are not filters. A query must be constrained so that its potential results satisfy the rules. Using the Firebase web SDK syntax common in 2020:

const snapshot = await firebase.firestore()
  .collection('articles')
  .where('published', '==', true)
  .get();

Querying every article and expecting Firebase to remove drafts will fail. Also, every field in a published article is readable; keep editorial notes elsewhere.

4. Add authorization only where needed

If your application needs user-owned records, Firebase Authentication provides an identity that rules can check:

match /privateProfiles/{userId} {
  allow read: if request.auth != null
              && request.auth.uid == userId;
}

This grants authenticated users read access to their own profile document and grants no writes by itself.

Checking only request.auth != null means any authenticated account qualifies. That is not equivalent to “administrator,” especially when anyone can register.

For editor access, use a carefully designed authorization model, such as trusted custom claims. Never let a user grant themselves an administrator role by editing an ordinary profile field.

If you permit client writes, validate allowed fields, types, ownership, and immutable values. Authentication answers who made a request; it does not establish that the submitted data is safe.

5. Test allowed and forbidden requests

Use the Firebase console's rule-testing facilities for quick checks, and the Local Emulator Suite for repeatable development tests. With the Firebase CLI installed and emulators configured, you can start the Firestore emulator with:

firebase emulators:start --only firestore

Ensure your test client connects to the emulator, not production.

At minimum, verify that:

1. An anonymous visitor can read a published article.
2. An anonymous visitor cannot read a draft or private profile.
3. An anonymous visitor cannot create, update, or delete an article.
4. One authenticated user cannot read another user's private profile.
5. The actual queries used by your website succeed under the new rules.

Testing only the happy path misses the most important security failures. Use a client SDK or rules-testing tool for permission checks; a successful Admin SDK request does not prove that client rules allow access.

6. Deploy and verify the correct project

Confirm that firebase.json points to the intended rules file, then deploy explicitly:

firebase deploy --only firestore:rules --project YOUR_PROJECT_ID

Review the published rules in the console and test the live application's essential read paths. If you use the console directly, make sure you publish your edits.

Keep the deployed rules in version control. Otherwise, a later deployment can silently replace a console fix with an older permissive file.

Common pitfalls after the initial fix

Treating a hidden URL as private. If a document is readable without authentication, assume someone can access it independently of your navigation.

Securing Firestore but forgetting uploads. Review Storage rules separately, including who can upload, overwrite, and download files.

Allowing all signed-in users to write. A sign-in requirement is not an editorial permission system.

Ignoring historical exposure. Tightening rules prevents future unauthorized access; it cannot undo earlier reads. If sensitive records were exposed, assess the scope, review available logs, and rotate any exposed secrets as appropriate.

Expecting rules to eliminate every cost risk. Public content remains available for automated retrieval. Monitor usage and set budget alerts; alerts are notifications, not a hard spending cap.

Takeaway

Firebase is not warning you merely because your website has visitors. Investigate the specific resource, inspect its deployed rules, and confirm what anonymous and authenticated clients can actually do.

Public content can have intentional public read access. Private data needs explicit protection, and writes should require a justified, tested authorization path. Fix the permissions first; treat the disappearance of an email as secondary confirmation, not the security test.