Ask an AI to “audit my Firebase” and it parrots the console’s own warnings back at you. The real config bugs hide in the gaps: a Storage rule that lets any signed-in user read every object, a public HTTP function with no App Check, a missing composite index that only fails under production load. These 15 prompts each interrogate one Firebase surface, one finding type at a time.
Paste them into Claude Opus 4.7, GPT-5.5, or Gemini 3.1 Pro — all three read a 1M-token context (as of June 2026), so you can drop your whole firestore.rules, storage.rules, firebase.json, and the functions/ directory in a single message and let the model cross-reference rules against the queries that actually run.
TL;DR
- Run the rules audits first (templates 1-3). Most Firebase leaks live in Security Rules, and a leak there invalidates every other check.
- Anchor each prompt to one file and one finding type (access, data shape, index, trigger). Broad “review everything” prompts produce vague output.
- Firebase changed under your feet: Cloud Functions default to 2nd gen now, Node 18 was decommissioned in October 2025, and the old
functions.config()store stopped serving values after the Cloud Runtime Configuration API shut down on December 31, 2025. Templates 5, 6, 12, and 13 reflect that. - App Check enforcement on a callable needs
firebase-functions4.0.0+ andenforceAppCheck: true; it can take up to 15 minutes to take effect after deploy.
Who this is for
Indie devs shipping Firebase backends, code reviewers auditing rule changes, founders preparing for a launch-day traffic spike, and security engineers reviewing Cloud Functions. Skip these if you only use Firebase for Analytics or Remote Config — they target apps built on Firestore, Realtime Database, Storage, Cloud Functions, and Auth.
What Security Rules can and can’t do
Two facts shape every prompt below, straight from the Firebase security checklist:
- Security Rules enforce authentication, field-level authorization, type checks, and field immutability. They cannot do cross-document queries, call external APIs, or rate-limit. Anything beyond that belongs in a Cloud Function.
- Cloud Functions have full, unrestricted write access to Firestore by default. A function that handles requests from multiple users must check who the caller is and what they’re allowed to do before touching data — Rules do not protect you there.
That split is why this set audits both surfaces. Templates 1-4 and 11 cover Rules; templates 5-7 and 10 cover the function side.
How to feed the model
Every prompt below works best with six things in the message:
- Role: Firebase security reviewer (not “helpful assistant”).
- Context: the actual
*.rules,firebase.json, andfunctions/source — paste files, not summaries. - Goal: one deliverable (a findings table, a deploy checklist, a test file).
- Constraints: don’t rewrite, don’t auto-format, don’t guess SDK versions.
- Output format: numbered findings or a markdown table with
file:line. - Signal: tell it what a bad rule looks like (e.g.
if request.auth != null) so it flags the pattern.
15 copy-ready prompt templates
1. Firestore rules coverage audit
Run first; most Firebase leaks live in rules.
You are a Firebase security reviewer. Audit `firestore.rules` below. For each collection / subcollection: (1) Is there a `match` block? (2) For each command (read / get / list / create / update / delete) — what condition gates it? (3) Are there overly broad `match /{document=**}` wildcards? (4) Where do rules use `request.auth.uid` correctly vs incorrectly? Output: path | read | write | risks.2. Storage rules audit
Audit `storage.rules`. For each bucket path: (1) Read / write conditions, (2) Does the path encode ownership (e.g., `users/{userId}/...`) and does the rule enforce that the prefix matches `request.auth.uid`? (3) Are file size / content-type limits enforced in rules? (4) Any rules using `request.auth != null` (too loose — any signed-in user can read)? File:line.3. Realtime Database rules audit
If `database.rules.json` exists, audit it: (1) `.read` and `.write` on root — should not be `true`, (2) Per-path conditions reference `auth.uid` against the path variable, (3) `.validate` rules constrain data shape (type, length, allowed keys), (4) Are indexes (`.indexOn`) declared for queried fields? Output findings + severity.4. Firestore composite index audit
Audit `firestore.indexes.json` against the query patterns in app code. For each query that combines (where + orderBy) or multiple where clauses: (1) Does a matching composite index exist? (2) Any indexes declared but never used? (3) Index fan-out cost concerns (very high write volume tables)? List: query | needed index | currently present.5. Cloud Functions trigger audit
These functions default to 2nd gen (Cloud Run functions) — note onRequest/onCall/onDocumentWritten style, not functions.https.onRequest.
Audit Cloud Functions trigger config (assume 2nd gen / Cloud Run functions). (1) HTTP triggers — which are public? Which need App Check or auth middleware? (2) Firestore / RTDB triggers — could they recurse (a write that triggers another write to the same path)? (3) Scheduled / PubSub functions — frequency vs cost, (4) functions missing explicit timeout / memory / concurrency / maxInstances. Output: function | trigger | risk.6. Cloud Functions input validation review
In a 2nd-gen callable, the caller arrives on request.auth and request.data (1st gen used context.auth / data); flag which API the code targets.
Review each callable / HTTP Cloud Function for: (1) Auth check at the top — `request.auth` (2nd gen onCall) or `context.auth` (1st gen) for callables, verified JWT for raw HTTP; remember functions have unrestricted DB write access so the caller MUST be checked. (2) Input schema validation (zod / valibot / manual). (3) Rate limiting or App Check enforcement (`enforceAppCheck: true`). (4) Output shape — no leaking internal fields. List findings as function | gap | fix.7. App Check coverage audit
Enforcing App Check on a callable needs firebase-functions 4.0.0+ and enforceAppCheck: true; it can take up to 15 minutes to take effect after deploy, so don’t panic during the window.
Map App Check coverage. (1) Which Firebase products have enforcement enabled (infer from code; flag what needs console confirmation)? (2) Which callable functions set `enforceAppCheck: true` (or check `request.app` for 2nd gen)? (3) Any client SDK init that calls Firebase without initializing App Check (reCAPTCHA Enterprise / App Attest / Play Integrity)? (4) Are debug tokens active in production code paths? Output: surface | enforced? | remediation.8. Auth provider configuration review
Review Firebase Auth provider setup: (1) Which providers are enabled (Google, Apple, Email, Anonymous, Custom)? (2) Anonymous auth — is there a graduation path to a real account? (3) Email link / password reset — are templates customized and rate limits set? (4) Custom claims usage — is the issuer trusted (only set by admin SDK)? Output: provider | config | gap.9. Firebase Hosting rewrites and headers
Review `firebase.json` hosting config: (1) Rewrites — any wildcard that masks 404s incorrectly? (2) Headers — security headers present (CSP, X-Frame-Options, Referrer-Policy)? (3) Cache-Control on static vs dynamic assets, (4) i18n config consistency. List issues.10. Custom claims and admin SDK audit
Find every place the Admin SDK sets custom claims. For each: (1) Is the call wrapped in a function that's admin-only? (2) Could user input flow into the claim value? (3) Are claim names colliding with reserved (aud, sub, iss)? (4) Is claim size kept under 1000 bytes? Findings.11. Firestore data validation rules audit
Beyond access control, audit Firestore rules for DATA SHAPE validation: (1) `request.resource.data.keys()` constrained to allowed keys? (2) Types enforced (`is string`, `is timestamp`)? (3) Length / range constraints on user-supplied fields? (4) Immutable fields (e.g., createdAt, ownerId) protected from update? List gaps.12. Cloud Functions cost & cold-start review
2nd-gen functions bill per-100ms and support concurrency (multiple requests per instance) and minInstances — ask the model to use both levers.
Review Cloud Functions (2nd gen) for cost / cold-start issues: (1) functions invoked on every write of a high-volume Firestore collection, (2) memory over-provisioned (e.g. 512MiB+ where 256MiB suffices), (3) minInstances set when bursty traffic doesn't need warm instances, (4) concurrency left at 1 when the handler is I/O-bound and could serve many requests per instance, (5) work better suited to a direct client SDK call. Output: function | issue | savings estimate.13. Environment and secret review
functions.config() is dead: the Cloud Runtime Configuration API was shut down on December 31, 2025, so firebase functions:config:get no longer returns values. Config now lives in .env files, parameterized params, or Cloud Secret Manager — audit accordingly.
Audit Firebase secrets and env (assume functions.config() is decommissioned). (1) Any leftover `functions.config()` reads or `runtimeconfig.json` that must migrate to .env / defineSecret() / Secret Manager? (2) Plaintext API keys in `.env` that belong in Secret Manager (anything that grants spend or PII access)? (3) Client-side Firebase config (apiKey) — public by design, but flag if treated as a secret. (4) `.env*` files or service-account JSONs committed to the repo? Output file:line per finding.14. Multi-environment isolation audit
This project uses [projects] (dev / staging / prod). Audit: (1) Are project IDs sourced from env (not hardcoded)? (2) Are emulator configs used in dev / test? (3) Any code path that could call prod from a dev runtime? (4) Are auth users segregated per project? Findings.Variables to swap: [projects], e.g. my-app-dev, my-app-staging, my-app-prod.
15. Firebase findings → migration plan
Run last; converts findings into a deploy sequence.
Take all Firebase audit findings above. Group into deploy steps: (1) Rules changes (deploy first, test with emulator), (2) Index additions (deploy before queries that need them), (3) Function changes (deploy after rules), (4) Console changes (App Check, auth providers — note manual). Output: ordered checklist with rollback per step.The seven leaks these prompts catch most
In order of how often they show up in real Firebase repos:
allow read, write: if request.auth != null— any signed-in user reads everything. The single most common Firebase leak; almost always wrong.- Test-mode rules that ship to production. The default
allow read, write: if request.time < ...template expires to open, and plenty of apps launch before the date passes. - Callable functions with no App Check on paid or quota-burning features — the abuse surface is the whole feature.
- Custom claims trusted from the client. Only the Admin SDK should set them, and the claim payload must stay under 1000 bytes.
- Queries deployed before their composite index. The first production request that needs the index fails outright.
- Recursive Firestore triggers with no depth guard — a write fires a write fires a write, and the bill follows.
- Service-account JSON committed to the repo — full project takeover from one leaked file.
How to push results further
- Run the rules audit (templates 1-3) before anything else. A leak here invalidates every other check.
- Dry-run rule changes against fixture data with the Firebase Emulator Suite and the Rules Unit Testing SDK before you deploy.
- Demand
request.resource.data.keys()constraints in Firestore rules — they’re cheap and block surprise fields a client tries to write. - Pair every callable-function review with an App Check check; the two failure modes travel together.
- Snapshot
firestore.indexes.jsonand*.rulesinto/firebase/baseline/and diff before each PR. - For cost reviews, attach a billing export to BigQuery — static review alone never sees the dollar impact.
- Re-run the full set after every Firebase product or SDK upgrade. Defaults and generations change (the 1st-gen → 2nd-gen shift moved more than half these checks).
FAQ
- Which model should I run these in? Any of the three 1M-context models — Claude Opus 4.7, GPT-5.5, or Gemini 3.1 Pro (as of June 2026) — can hold a full Firebase config. For security-rule reasoning, Opus 4.7 (87.6% SWE-bench Verified) tends to give the tightest findings; Gemini 3.1 Pro is the cheapest at $2/$12 per 1M tokens if you’re auditing a large
functions/tree. - My client-side Firebase
apiKeyis in source. Is that a leak? No. It identifies the project, not a secret; security comes from Security Rules and App Check. Treat it as public, and flag only if code uses it as if it were a secret. - Should I run these on every PR? Only when a PR touches
*.rules,firestore.indexes.json,functions/, or Auth config. Other PRs don’t need the pass. - Can AI write the rules for me? For a first draft, yes — but always run templates 1, 2, and 11 on anything it generates. Models very reliably emit
request.auth != null, which is too loose. - How do I test rules without deploying? Use the Firebase Emulator Suite plus the Rules Unit Testing SDK. These prompts cover the structural audit; the emulator covers actual behavior against fixtures.
- Does
functions.config()still work? No. The Cloud Runtime Configuration API behind it shut down on December 31, 2025, sofirebase functions:config:getreturns nothing. Migrate to.envfiles, parameterized config (defineString/defineSecret), or Cloud Secret Manager — template 13 audits the migration. - What about Firebase Extensions? Audit each extension’s service-account scopes; they often request broad permissions. Add a row in template 5 for every installed extension.