Firebase Security Rules中`if false`是否可选及未定义规则相关问题

Let’s break down your two key questions about securing your database:

1. Blocking Delete Operations: Do You Need allow delete: if false;? #

Short answer: No, you don’t have to. Firestore security rules operate on a "deny by default" basis—any operation you don’t explicitly allow is automatically blocked.

So if your rules only define create and update permissions for your collection, like this:

match /your-target-collection/{doc} {
  allow create: if <your-validation-logic>;
  allow update: if <your-validation-logic>;
}

All delete requests to that collection will fail outright, no extra allow delete: if false; line required.

That said, adding the explicit allow delete: if false; is a valid choice if you want to make your intent 100% clear to anyone reviewing the rules later (your team, future you). But it’s not a requirement for enforcing the block.

2. Securing Undefined Collections Against Reverse-Engineered APKs #

Great question—and the answer is yes, those requests will be blocked.

Firestore’s default behavior is to reject all requests to paths (collections/documents) that don’t have any matching rules defined. Even if a hacker reverse-engineers your APK and tries to create or write to a random, unplanned collection (e.g., /hacker-data/{doc}), Firestore will deny the request because there’s no allow rule granting access to that path.

For extra peace of mind, some developers add a catch-all rule at the root of their ruleset to explicitly deny all unspecified paths, like this:

match /{document=**} {
  allow read, write: if false;
}

But even without this, the default "deny by default" behavior will protect you from these kinds of unauthorized requests.

内容的提问来源于stack exchange，提问作者JarsOfJam-Scheduler