Firebase rules trust an email domain without verifying the address

Symptom

Domain checks on request.auth.email look locked to your company. Anyone who signs up with an unconfirmed address on that domain still passes.

Root cause

Firebase's Firestore insecure-rules page, last updated 2026-10-16, documents access for unverified email addresses. Checking that an email belongs to a domain is generally a good practice, and emails are not always verified during sign-in until the user completes an additional step after receiving a verification email. The page says to validate that the email does in fact belong to the user. The not-recommended example is labeled any user can sign in with an arbitrary email address. It allows read when request.auth != null and request.auth.email.endsWith('@example.com'). The documented fix, narrow access to verified emails only, keeps those checks and adds request.auth.email_verified. The general insecure-rules page in the same family covers open access, access for any authenticated user, and cascading Realtime Database rules. Generated apps often get the domain check alone from a prompt that only asks for company-email access. Firebase Auth's manage-users guide is the client-side counterpart: sendEmailVerification sends the verification email, and the User object exposes emailVerified, which Security Rules read as request.auth.email_verified.

Before and after

The before rule is the Firestore insecure-rules example for an unverified email domain. The after rule is the documented fix, which also requires email_verified. Use the domain your own rule already checks.

allow read: if request.auth != null
&& request.auth.email.endsWith('@example.com');

allow read: if request.auth != null
&& request.auth.email_verified
&& request.auth.email.endsWith('@example.com');

In this project's Firebase rules only. Do not open any other Firebase project.

1. Search this project's Cloud Firestore rules for request.auth.email and for endsWith on an email domain. Search Realtime Database and Storage rules for the same kind of domain check.

2. On each Cloud Firestore rule that grants access from an email domain, keep request.auth != null and add && request.auth.email_verified. The Firestore insecure-rules page shows this shape:

allow read: if request.auth != null
            && request.auth.email_verified
            && request.auth.email.endsWith('@example.com')

Replace @example.com with the domain that rule already checks. Do not widen the domain.

3. Do not treat a client-editable profile email, or an email field on a document the user can write, as proof the address is verified. The flag in these rules is request.auth.email_verified.

4. In this project's client, send the verification email with Firebase Auth sendEmailVerification. Read emailVerified on the User before the app treats that session as allowed into private data.

5. Deploy the rules to your own project. In the Rules Playground, run a read of private data as a signed-in user with email_verified set to false. That read must be denied.

Do not print tokens, API keys, or other secrets. Do not touch other projects.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

1. In your own Firebase console, open Rules and search for email domain checks. A rule that uses request.auth.email or endsWith on a domain, and grants access without request.auth.email_verified, is the failure.
2. In the Rules Playground for your own project, run a read of private data as a signed-in user with email_verified set to false. The read should be denied.
3. In your own app, confirm sign-up sends a verification email through Firebase Auth, and a signed-in user with emailVerified false cannot read private data. Do not point this check at any other project.

Common questions

Sources

• Firebase: Firestore insecure rules (access for unverified email addresses)
• Firebase: Avoid insecure rules
• Firebase Auth: Manage users (sendEmailVerification and emailVerified)

Same platform

• A database function returns rows the table policy hides
• Supabase tables ship with row level security off
• A policy uses USING (true) on private rows