# Firestore and Cloud Storage Security Rules Checklist DreamLabs is an AI-powered app development agency in California — a fractional product team for mobile and web apps, from strategy to launch. Firebase lets a small team ship a real app without running a server, and Security Rules are what make that safe. Firebase's own docs say your API key only identifies your project; IAM, Security Rules and App Check decide who gets in. Get the rules right and the config in your app is harmless by design, a customer's security questionnaire becomes a short reply, and every new feature ships with a rule and a test instead of a question mark. This checklist covers Firestore and Cloud Storage in 24 checks. Each one says what to look for, why it matters, how to test it in the console, the emulator or a terminal, and which Firebase documentation backs it. Run the tests only against projects you own, ideally a staging copy. Updated October 7, 2026. 24 checks in 7 sections. Free and ungated. ## Start here: what can a stranger reach? Firebase is clear that your web API key and project ID are public by design: they identify your project, and Security Rules decide who gets in. These checks show what anyone holding your app's config can do today. - [ ] **No rule grants access to everyone: no `allow read, write: if true`, and no condition that only compares `request.time` to a date.** Why it matters: Firebase's own warning about open rules is that anyone who guesses your project ID can steal, modify or delete the data. A condition that only checks the date is the same open door until that date passes. Projects created in test mode start with rules that let anyone read and overwrite your data, so this is the first thing to look for. How to test: Open Firestore > Rules in the Firebase console (or the rules file named in `firebase.json`) and search for `if true` and `request.time`. Then open Rules playground, pick a read on a private path such as `/users/some-id`, set Authentication to unauthenticated, and click Run. Finally, ask the REST API for a collection with no token at all: Firestore evaluates unauthenticated REST requests against your rules, so a private collection should answer with a 403. ```shell # Replace PROJECT_ID and the collection name. Expect 403 PERMISSION_DENIED. curl -s "https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/(default)/documents/users?pageSize=5" ``` Source: [Firebase: Fix insecure rules (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/insecure-rules#open_access) - [ ] **Broad wildcard matches such as `match /{document=**}` don't quietly override the specific rules beneath them.** Why it matters: When more than one match statement applies to a document, Firestore allows the request if any of them allows it. One permissive catch-all, often left over from early development, cancels every careful rule written after it. How to test: List every `match` block that contains `=**`. For each one, ask whether everything it grants is acceptable for every path it covers. In Rules playground, try a sensitive path that a specific rule should deny; if it comes back allowed, an overlapping match is winning. Source: [Firebase: Structuring Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/rules-structure#overlapping_match_statements) - [ ] **The rules running in production are the rules in your repository, and every Firestore database in the project has its own reviewed rules file.** Why it matters: A CLI deploy overwrites rules edited in the console, and console edits never make it back to your repo, so the two drift apart. A project can also hold several Firestore databases: each named database gets its own rules, deployed through the Firebase CLI, and the console and Admin SDK only deploy rules to the default database. How to test: Compare the Rules tab in the console with the rules file in your repo. List the project's databases and confirm each one is mapped to a rules file in `firebase.json`. From then on, deploy rules only from the repo. ```shell firebase firestore:databases:list firebase deploy --only firestore:rules ``` Source: [Firebase: Manage and deploy Firebase Security Rules](https://firebase.google.com/docs/rules/manage-deploy#use_the_firebase_console) ## Signed in is not the same as allowed Most real-world rule problems aren't open databases. They're rules that let any signed-in user do what only one user should. - [ ] **No rule treats `request.auth != null` as permission to read or change other people's data.** Why it matters: Firebase lists 'any logged-in user has read and write access' among its insecure patterns. Unless you've turned off sign-up, anyone can create an account in your project using the public API key, so 'signed in' often just means 'registered'. How to test: Search your rules for `auth != null` and review every match where it's the only condition. Then prove it from outside: create a throwaway account with the Auth REST API and the API key from your app's config, and repeat the earlier request as that user. Do this against a staging project, or delete the test user afterwards. ```shell # 1. Create a test user (email/password sign-in must be enabled) curl -s 'https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=API_KEY' \ -H 'Content-Type: application/json' \ --data-binary '{"email":"rules-test@example.com","password":"CHOOSE_A_PASSWORD","returnSecureToken":true}' # 2. Copy idToken from the response and read another user's data as this user curl -s -H "Authorization: Bearer ID_TOKEN" \ "https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/(default)/documents/users?pageSize=5" ``` Source: [Firebase: Fix insecure rules (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/insecure-rules#access_for_any_authenticated_user) - [ ] **If Anonymous Authentication is on, non-public data requires a real sign-in method or a verified email.** Why it matters: Firebase's security checklist puts it plainly: anyone could create an anonymous account in your project, and anonymous auth is not a replacement for user sign-in. Anonymous users pass `request.auth != null` like everyone else. How to test: Check Authentication > Sign-in method for Anonymous. If it's enabled, protected reads and writes should also require `request.auth.token.firebase.sign_in_provider != 'anonymous'` or `request.auth.token.email_verified == true`. In Rules playground, rerun a protected request as an authenticated anonymous user and confirm it's denied. From outside, the same signUp endpoint returns an anonymous token when the provider is on. ```shell # Returns an anonymous idToken if Anonymous sign-in is enabled curl -s 'https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=API_KEY' \ -H 'Content-Type: application/json' --data-binary '{"returnSecureToken":true}' ``` Source: [Firebase: Security checklist](https://firebase.google.com/support/guides/security-checklist#use-security-rules-that-require-sign-in-method) - [ ] **Rules that trust an email address or domain also require `request.auth.token.email_verified`.** Why it matters: Emails aren't always verified at sign-in. A rule meaning 'anyone with an @yourcompany.com address' can be satisfied by someone who typed that address without owning it. How to test: Search your rules for `email`. Every condition on an address or domain should sit next to an `email_verified == true` check. Cover it with an emulator test that signs in with a matching but unverified email and expects a denial. ```javascript // Emulator test (see the unit-test item for setup) const unverified = testEnv.authenticatedContext('u1', { email: 'someone@yourcompany.com', email_verified: false, }).firestore(); await assertFails(getDoc(doc(unverified, 'internal/roadmap'))); ``` Source: [Firebase: Fix insecure rules (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/insecure-rules#access_for_unverified_email_addresses) - [ ] **Roles and permissions come from custom claims set on a server, or from documents users can't write to.** Why it matters: Firebase says custom claims should only be set from a privileged server environment with the Admin SDK, and the ID token delivers them in a form users can't tamper with. A role stored on a user's own profile document, which that user is allowed to update, is a role they can give themselves. How to test: Find every rule that checks a role (`token.admin`, `.data.role`, `isAdmin`). For claims, confirm that only server code calls `setCustomUserClaims`. For role documents, confirm their owners can't change the role field (see the field allowlist check). Emulator test: as a normal user, update your own document with `role: 'admin'` and assert it fails. Source: [Firebase: Control access with custom claims and security rules](https://firebase.google.com/docs/auth/admin/custom-claims#set_and_validate_custom_user_claims_via_the_admin_sdk) ## Writes that keep your data honest - [ ] **New documents are stamped with the caller's own ID, and updates can't change who owns a document.** Why it matters: Checking ownership of the existing document isn't enough. Firebase's content-owner pattern checks `request.resource.data` on create, and both the stored and the incoming document on update, so nobody can create records in someone else's name or hand a record to another account. How to test: For each owned collection, look for `allow create: if request.auth.uid == request.resource.data.ownerId` and an update rule that checks the owner on both `resource.data` and `request.resource.data`. Emulator test: as Bob, create a document with `ownerId: 'alice'`, then try to update one of Alice's documents. Both should fail. Source: [Firebase: Fix insecure rules (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/insecure-rules#content-owner-only) - [ ] **Updates are limited to the fields a user is allowed to change, using `request.resource.data.diff(resource.data).affectedKeys().hasOnly([...])`.** Why it matters: Rules are schemaless. Without a field allowlist, a user who may edit their profile may also edit `role`, `plan`, `credits` or `verified` on it. Firebase calls the `hasOnly()` approach generally more secure, because a field you add later stays locked until you allow it. How to test: Every `allow update` should carry an `affectedKeys().hasOnly()` list or an equivalent check. Emulator test: as the document owner, update a protected field and assert it fails, then update an allowed field and assert it succeeds. ```firestore-rules // firestore.rules allow update: if request.auth.uid == resource.data.ownerId && request.resource.data.diff(resource.data).affectedKeys() .hasOnly(['displayName', 'photoURL', 'bio']); ``` Source: [Firebase: Control access to specific fields (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-fields#allowing_only_certain_fields_to_be_changed) - [ ] **New documents are validated: required fields with `hasAll()`, permitted fields with `hasOnly()`, and types with the `is` operator.** Why it matters: Nothing at the database level stops a client writing a string where you expect a number, or an extra field you never designed for. In an app with no server of its own, rules are the only server-side validation there is. How to test: Review each `allow create` for key and type checks. Emulator test: create a document with an extra field, one with a missing required field and one with a wrong type. Each should fail. Source: [Firebase: Control access to specific fields (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-fields#enforcing_field_types) ## Reads that show only what they should - [ ] **Fetching one document (`get`) and running queries (`list`) have separate rules, and queries must be scoped to the caller.** Why it matters: Being able to open one document by ID is very different from being able to download a whole collection. Rules are not filters: a query only succeeds if every document it could return is allowed. That means you can require queries to filter on the caller's ID, and cap their size with `request.query.limit`. How to test: Look for plain `allow read` on sensitive collections and consider splitting it into `get` and `list`. Emulator test: run an unfiltered query as a normal user and assert it fails, then run the same query filtered to the user's own documents and assert it succeeds. ```javascript const bob = testEnv.authenticatedContext('bob').firestore(); await assertFails(getDocs(collection(bob, 'orders'))); await assertSucceeds(getDocs(query(collection(bob, 'orders'), where('ownerId', '==', 'bob')))); ``` Source: [Firebase: Securely query data (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-query#rules_are_not_filters) - [ ] **Private fields (email, phone, internal notes, payment status) live in separate documents, not inside documents other users can read.** Why it matters: Reads are all or nothing per document. Firebase says outright that security rules alone can't stop users reading specific fields within a document, so a public profile that also stores a phone number publishes the phone number. How to test: For every collection other users can read, list its fields and mark anything private. Move those fields to a subcollection such as `/users/{uid}/private/{doc}` with owner-only rules, and add an emulator test proving a second user can read the public document but not the private one. Source: [Firebase: Control access to specific fields (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-fields#allowing_read_access_only_for_specific_fields) - [ ] **Every subcollection and every collection group query has its own explicit rule.** Why it matters: Rules apply only at the path they match: access granted on `cities` doesn't extend to `cities/{id}/landmarks`. Collection group queries need `rules_version = '2'` and a `{path=**}` match, which is easy to write more broadly than you meant. How to test: Map every path your app reads or writes, subcollections included, against your match blocks. Unmatched paths are denied, which is safe. Any `{path=**}` match deserves a test proving one user can't query another user's documents across the group. Source: [Firebase: Structuring Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/rules-structure#hierarchical_data) ## Cloud Storage: files get the same care as data - [ ] **Storage rules start from deny-all and grant access by path, with each user's files under a path containing their UID.** Why it matters: Firebase recommends initializing Storage rules to deny all access and adding rules as you build. Its user-private pattern, `match /users/{userId}/{fileName}` with `request.auth.uid == userId`, keeps one user's uploads away from everyone else. How to test: Open Storage > Rules. Flag `if request.auth != null` on broad paths and `if true` anywhere outside a deliberately public folder. Emulator test: seed a file under `users/alice/` with `withSecurityRulesDisabled`, then as Bob try to read and overwrite it. Both should fail. ```javascript import { ref, getBytes, uploadBytes } from 'firebase/storage'; const bob = testEnv.authenticatedContext('bob').storage(); await assertFails(getBytes(ref(bob, 'users/alice/id-card.jpg'))); await assertFails(uploadBytes(ref(bob, 'users/alice/avatar.png'), new Uint8Array([1]))); ``` Source: [Firebase: Use conditions in Firebase Security Rules for Cloud Storage](https://firebase.google.com/docs/storage/security/rules-conditions#user_private) - [ ] **Uploads are limited by size and content type.** Why it matters: Without limits, anyone allowed to upload can store files of any size or type in your bucket, on your bill. Storage rules can check `request.resource.size` and `request.resource.contentType` before the upload is accepted. How to test: Each upload rule should include something like `request.resource.size < 5 * 1024 * 1024 && request.resource.contentType.matches('image/.*')`. Emulator test: upload an oversized file and a non-image to an image path. Both should fail. Source: [Firebase: Understand Firebase Security Rules for Cloud Storage](https://firebase.google.com/docs/storage/security) - [ ] **Listing a folder is a separate decision from reading a file: `allow list` appears only where browsing is intended.** Why it matters: `allow read` covers both, so anyone who may open a file under a path may also enumerate every file name under it. Storage rules let you split read into `get` and `list` (listing requires rules version 2). How to test: Search Storage rules for `allow read` on folders holding user files and consider `allow get` instead. Emulator test: call `listAll()` on a user folder as a signed-out client and assert it fails. ```javascript import { ref, listAll } from 'firebase/storage'; const anon = testEnv.unauthenticatedContext().storage(); await assertFails(listAll(ref(anon, 'users/alice'))); ``` Source: [Firebase: Learn the core syntax of the Firebase Security Rules for Cloud Storage language](https://firebase.google.com/docs/storage/security/core-syntax#granular_operations) - [ ] **Download URLs for private files aren't stored where other users can read them, and private files are fetched through the SDK.** Why it matters: A download URL is built for sharing; Firebase describes it as the option for when you 'just want a URL to share'. By contrast, the SDK's direct-download functions (`getBlob()`, `getBytes()`) 'allow for finer-grained access control via Firebase Security Rules'. How to test: Search your Firestore data and code for stored `firebasestorage.googleapis.com` URLs and check who can read the documents that hold them. Open one in a private browser window with no sign-in. If the file loads, the URL itself is the access control, so treat it like a password. Source: [Firebase: Download files with Cloud Storage on Web](https://firebase.google.com/docs/storage/web/download-files#download_data_directly_from_the_sdk) - [ ] **The bucket's IAM policy doesn't grant `allUsers` or `allAuthenticatedUsers`.** Why it matters: Requests made through the Google Cloud Storage APIs use Cloud Storage access control, not Firebase Authentication and Storage Security Rules. An IAM grant to `allUsers` makes objects readable by anyone on the internet, whatever your rules say. How to test: Print the bucket's IAM policy and look for `allUsers` or `allAuthenticatedUsers` in any binding. Your bucket name is the `storageBucket` value in your app's Firebase config. ```shell gcloud storage buckets get-iam-policy gs://BUCKET_NAME ``` Source: [Firebase: Integrate with Google Cloud (Cloud Storage)](https://firebase.google.com/docs/storage/gcp-integration#google-cloud-storage-apis) ## Around the rules: keys, servers and abuse - [ ] **Service account keys never ship in a client app, and server code that uses the Admin SDK checks who's calling before it touches data.** Why it matters: Server client libraries bypass all Firestore Security Rules and authorize through IAM instead. A service account key in a web bundle or mobile app is full database access for whoever extracts it. A Cloud Function that acts with Admin rights for an unverified caller is the same gap with more steps. How to test: Search your built web bundle and app source for private key material (command below). In every callable function, confirm the handler rejects calls without `request.auth` and acts on `request.auth.uid`, never on a user ID sent in the request body. ```shell grep -rnE "BEGIN PRIVATE KEY|private_key|client_email" dist/ build/ src/ 2>/dev/null ``` Source: [Firebase: Get started with Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started) - [ ] **Your Firebase API key is restricted to Firebase APIs, and anything else (Maps, Gemini) uses its own restricted key.** Why it matters: Firebase API keys are public by design because authorization comes from IAM, Security Rules and App Check. That only holds while the key is limited to Firebase APIs. Firebase says never to include the Gemini Developer API in the allowlist of a publicly accessible key, and a Gemini API key should never be in your code or config at all. How to test: In Google Cloud console > APIs & Services > Credentials, open the key from your app's config and read its API restrictions. It should list only Firebase-related APIs, and not Generative Language API. Source: [Firebase: Learn about using and managing API keys for Firebase](https://firebase.google.com/docs/projects/api-keys#use-separate-keys-for-specific-apis) - [ ] **App Check is enforced for Cloud Firestore and Cloud Storage once your real users are sending valid tokens.** Why it matters: Once enforcement is on for a product, Firebase rejects every unverified request to it, so scripts and forged clients built from your public config get turned away. App Check complements Authentication and rules; it doesn't decide which user may see which document. How to test: In the Firebase console, open Security > App Check > APIs and read the request metrics for Firestore and Storage. 'Unknown origin' requests are traffic that doesn't look like your app. When you're confident enforcing won't lock out legitimate users (older app versions show up as 'Outdated client'), click Enforce; it can take up to 15 minutes to apply. Afterwards, the unauthenticated REST request from the first check should be rejected. Source: [Firebase: Enable App Check enforcement](https://firebase.google.com/docs/app-check/enable-enforcement) - [ ] **Authentication settings match how your app works: email enumeration protection on, and sign-up disabled if an admin creates accounts.** Why it matters: Enumeration protection stops people using your auth endpoints to discover which email addresses have accounts; it's on by default for projects created on or after September 15, 2023. If users should never register themselves, disabling user actions makes Firebase refuse client sign-ups with `auth/admin-restricted-operation`, which also closes the 'anyone can sign up' door from the second section. How to test: In the Firebase console, go to Security > Authentication > Settings and open User actions. Check email enumeration protection, and whether account creation by end users should be allowed at all. If you use email and password sign-in, Firebase also recommends tightening the Identity Toolkit API quota in Google Cloud console. Source: [Firebase: Authenticate with Firebase using password-based accounts (Web)](https://firebase.google.com/docs/auth/web/password-auth#enumeration-protection) - [ ] **Development, staging and production are separate Firebase projects, and production has budget alerts.** Why it matters: Firebase's checklist recommends separate projects so test data, test accounts and loosened test rules never touch production, and budget alerts so unusual traffic shows up before the invoice does. How to test: Confirm the config in your production build points at the production project, and that no development config ships with it. In Google Cloud Billing, confirm a budget with alert thresholds covers the production project. Source: [Firebase: Security checklist](https://firebase.google.com/support/guides/security-checklist#set-up-dev-and-staging-projects) ## Keep it closed - [ ] **Rules have unit tests that run in the Local Emulator Suite, in CI, on every change.** Why it matters: A rule that passes review today can break quietly with the next feature. Firebase recommends unit-testing rules with the emulator and adding the tests to CI, and treating rules like a schema: write the rule when you add the document type, not as a pre-launch chore. How to test: Install `@firebase/rules-unit-testing`. For each collection, write allow and deny cases for the owner, another user and a signed-out visitor. Run them with `firebase emulators:exec` locally and in CI, so a deny test that starts passing fails the build. ```javascript // rules.test.js (run: firebase emulators:exec --only firestore "npm test") import fs from 'node:fs'; import { initializeTestEnvironment, assertFails, assertSucceeds } from '@firebase/rules-unit-testing'; import { doc, getDoc, setDoc } from 'firebase/firestore'; const testEnv = await initializeTestEnvironment({ projectId: 'demo-rules-audit', firestore: { rules: fs.readFileSync('firestore.rules', 'utf8') }, }); const alice = testEnv.authenticatedContext('alice').firestore(); const bob = testEnv.authenticatedContext('bob').firestore(); const visitor = testEnv.unauthenticatedContext().firestore(); await assertSucceeds(setDoc(doc(alice, 'users/alice'), { ownerId: 'alice', displayName: 'A' })); await assertFails(getDoc(doc(bob, 'users/alice'))); await assertFails(getDoc(doc(visitor, 'users/alice'))); await assertFails(setDoc(doc(bob, 'users/alice'), { ownerId: 'bob' })); await testEnv.cleanup(); ``` Source: [Firebase: Build unit tests (Security Rules)](https://firebase.google.com/docs/rules/unit-tests#run_local_unit_tests_with_the_version_9_javascript_sdk) ## Frequently asked questions ### Is it safe that my Firebase config and API key are visible in my app? Yes, as long as two things hold. Firebase says API keys for Firebase services only identify your project; authorization comes from IAM, Security Rules and App Check. So the key needs to be restricted to Firebase APIs (and kept off the Gemini Developer API), and your rules need to pass this checklist. Service account keys and Gemini API keys are different: those must stay secret. ### Firebase emailed me that my Firestore database has insecure rules. Where do I start? With the first section. Open the Rules tab, look for `if true`, date-only conditions and `request.auth != null` used alone, and check broad `{document=**}` matches. Firebase's guidance for that alert is to change your rules and test them, with Rules playground for quick checks and the emulator for anything you want to keep. ### Do Cloud Functions and the Admin SDK follow my rules? No. Server client libraries bypass Firestore Security Rules and authorize through IAM, which is why server code has to check the caller itself. Rules protect what clients can do directly; your functions are responsible for everything they do on a user's behalf. ### Does App Check replace security rules? No. Firebase describes App Check and Authentication as complementary: App Check is about whether a request comes from your genuine app, while Authentication and rules decide what a given user may read and write. You want both. ### Can an AI coding agent write my rules? It can give you a good first draft, and Firebase's own docs now include prompts for coding agents. The catch is that an agent is usually optimizing for the feature working, and a rule that blocks a feature looks exactly like a bug. Keep the emulator tests from the last section in CI, so a loosened rule fails the build instead of shipping. ### I only have an hour. What should I do first? Run the outside-in tests from the first two sections: an unauthenticated REST read, then the same read as a freshly created test account. Then check Storage rules and the bucket's IAM policy. If those come back clean, you've covered the exposures that need no skill to find. ## Want proof your rules hold, not just a hunch? Start with our free surface check: we look at what your published app exposes to an ordinary visitor and send you the findings whether or not you hire us. If you want the whole project read, our AI-generated code audit goes through your database rules, every function and its authentication, storage rules and key exposure, with a reproduction for every finding, and most audits run one to two weeks. Planning a rebuild or a migration instead? Every migration starts with a two-week strategy sprint for a flat $4,000: a full features table, wireframes for your core flows and the scope of your first release, refunded in full if we don't move forward together. Builds are then quoted from the sprint's scope. - [Book a code audit](https://www.dreamlabs.pro/services/ai-generated-code-audit) - [See the strategy sprint](https://www.dreamlabs.pro/offerings) ## Sources 1. [Firebase: Fix insecure rules (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/insecure-rules): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 2. [Firebase: Get started with Cloud Firestore (quickstart)](https://firebase.google.com/docs/firestore/quickstart): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 3. [Firebase: Use the Cloud Firestore REST API](https://firebase.google.com/docs/firestore/use-rest-api): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 4. [Firebase: Firebase Auth REST API reference](https://firebase.google.com/docs/reference/rest/auth): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 5. [Firebase: Structuring Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/rules-structure): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 6. [Firebase: Manage and deploy Firebase Security Rules](https://firebase.google.com/docs/rules/manage-deploy): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 7. [Firebase: Create and manage Cloud Firestore databases](https://firebase.google.com/docs/firestore/manage-databases): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 8. [Firebase: Security checklist](https://firebase.google.com/support/guides/security-checklist): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 9. [Firebase: Control access with custom claims and security rules](https://firebase.google.com/docs/auth/admin/custom-claims): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 10. [Firebase: Control access to specific fields (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-fields): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 11. [Firebase: Securely query data (Cloud Firestore)](https://firebase.google.com/docs/firestore/security/rules-query): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 12. [Firebase: Use conditions in Firebase Security Rules for Cloud Storage](https://firebase.google.com/docs/storage/security/rules-conditions): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 13. [Firebase: Understand Firebase Security Rules for Cloud Storage](https://firebase.google.com/docs/storage/security): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 14. [Firebase: Learn the core syntax of the Firebase Security Rules for Cloud Storage language](https://firebase.google.com/docs/storage/security/core-syntax): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 15. [Firebase: Download files with Cloud Storage on Web](https://firebase.google.com/docs/storage/web/download-files): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 16. [Firebase: Download files with Cloud Storage on Android](https://firebase.google.com/docs/storage/android/download-files): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 17. [Firebase: Integrate with Google Cloud (Cloud Storage)](https://firebase.google.com/docs/storage/gcp-integration): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 18. [Google Cloud: Make data public (Cloud Storage)](https://cloud.google.com/storage/docs/access-control/making-data-public): Google Cloud docs, Last updated 2026-10-07 UTC, accessed 2026-10-07 19. [Google Cloud: Use IAM permissions (Cloud Storage)](https://cloud.google.com/storage/docs/access-control/using-iam-permissions): Google Cloud docs, Last updated 2026-10-07 UTC, accessed 2026-10-07 20. [Firebase: Get started with Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 21. [Firebase: Call functions from your app (callable functions)](https://firebase.google.com/docs/functions/callable): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 22. [Firebase: Learn about using and managing API keys for Firebase](https://firebase.google.com/docs/projects/api-keys): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 23. [Firebase: App Check](https://firebase.google.com/docs/app-check): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 24. [Firebase: Enable App Check enforcement](https://firebase.google.com/docs/app-check/enable-enforcement): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 25. [Firebase: Monitor App Check request metrics](https://firebase.google.com/docs/app-check/monitor-metrics): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 26. [Firebase: Authenticate with Firebase using password-based accounts (Web)](https://firebase.google.com/docs/auth/web/password-auth): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 27. [Firebase: Users in Firebase projects](https://firebase.google.com/docs/auth/users): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 28. [Firebase: Build unit tests (Security Rules)](https://firebase.google.com/docs/rules/unit-tests): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 29. [Firebase: Test your Cloud Firestore Security Rules (emulator)](https://firebase.google.com/docs/firestore/security/test-rules-emulator): Google (Firebase docs), Last updated 2026-10-06 UTC, accessed 2026-10-07 ## Links - Full page: https://www.dreamlabs.pro/services/firestore-security-rules-checklist - Code audit: https://www.dreamlabs.pro/services/ai-generated-code-audit - Offerings & pricing: https://www.dreamlabs.pro/offerings - Contact: https://www.dreamlabs.pro/contact