“Audit my Firebase” returns Firebase’s own console messages. Real Firebase config bugs hide in the gaps: a Storage rule that allows reads from any authenticated user, a Cloud Function with a public HTTP trigger and no App Check, a missing composite index that fails only under load. These 15 prompts each interrogate one Firebase surface.
Who this is for
Indie devs shipping Firebase backends, code reviewers auditing rule changes, founders preparing for traffic spikes, security folks reviewing Cloud Functions.
When not to use these prompts
Skip these for apps using Firebase only for analytics or remote config. They’re aimed at apps using Firestore / RTDB / Storage / Functions / Auth.
Prompt anatomy / structure formula
Every Firebase config audit prompt should carry six elements:
- Role: who the AI plays (architect / SRE / QA lead / release captain).
- Context: repo / framework / runtime versions / files or diff in scope.
- Goal: one concrete deliverable: review notes, plan, checklist, test file, handoff doc.
- Constraints: what AI MUST NOT do (don’t rewrite, don’t auto-format, don’t guess versions).
- Output format: numbered findings, markdown table, JSON, unified diff, or runnable code.
- Examples / signal: 1-2 examples of “good” output, or what bad output looks like.
Best for
- Pre-launch Firebase config review
- Cloud Functions deployment audit
- Firestore index and query plan check
- Storage bucket public-access audit
- App Check and abuse-prevention review
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
Audit Cloud Functions trigger config: (1) HTTP triggers — which are public? Which need App Check or auth middleware? (2) Firestore / RTDB triggers — could they recurse (write triggers a write)? (3) PubSub schedules — frequency vs cost, (4) Background functions missing timeout/memory limits. Output: function | trigger | risk.6. Cloud Functions input validation review
Review each callable / HTTP Cloud Function for: (1) Auth context check at the top (`context.auth` for callable, JWT for HTTP), (2) Input schema validation (zod / joi / manual), (3) Rate limiting or App Check enforcement, (4) Output shape (no leaking internal fields). List findings.7. App Check coverage audit
Map App Check coverage: (1) Which Firebase products have App Check enforcement enabled in console (you may need to ask, but list what code suggests)? (2) Which callable functions check `context.app`? (3) Any client SDK code calling Firebase without initializing App Check? (4) Are debug tokens active in production code paths? Findings + 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
Review Cloud Functions for cost / cold-start issues: (1) Functions invoked on every Firestore write of a high-volume collection, (2) Functions with high memory (>512MB) when 256MB would suffice, (3) min instances set unnecessarily, (4) Functions that do work better suited to a client SDK call. Output: function | issue | savings estimate.13. Environment and secret review
Audit Firebase secrets and env: (1) `firebase functions:config:get` values — any plaintext API keys that should be in Secret Manager? (2) Client-side Firebase config (apiKey) — note it's public by design, but flag if used as if it were a secret, (3) `.env` files committed accidentally? (4) Service-account JSONs in repo? File:line.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.Common mistakes
allow read, write: if request.auth != null: any signed-in user reads everything; almost always wrong.- Skipping App Check on callable functions that handle paid features: abuse surface is huge.
- Trusting custom claims set client-side: only Admin SDK should set them.
- Deploying queries before composite indexes: first prod request fails.
- Recursive Firestore triggers without depth guard: runaway costs.
- Committing service account JSON to repo: full project takeover.
- Mixing dev and prod project IDs in shared code paths: accidental prod writes.
How to push results further
- Always run rules audit (templates 1-3) before any other Firebase work; leaks here invalidate everything else.
- Use the Firebase Emulator Suite to dry-run rule changes against fixture data; pair with these prompts.
- Demand
request.resource.data.keys()constraints in Firestore rules; they’re cheap and prevent surprise fields. - Pair every callable function review with an App Check check.
- Snapshot
firestore.indexes.jsonand*.rulesin a/firebase/baseline/folder; diff before each PR. - For cost reviews, pair the audit with billing export to BigQuery; static review alone misses dollar impact.
- Re-run audits after each Firebase product upgrade; defaults occasionally change.
FAQ
- How is this different from the Supabase RLS review?: Firebase has many surfaces beyond DB rules (Storage, Functions, Auth, App Check, Hosting) and the rule language is different. The Supabase review is Postgres-flavored.
- Should I run these on every PR?: Only for PRs that change
*.rules,firestore.indexes.json,functions/, or Auth config. Other PRs don’t need it. - My client-side Firebase API key is in source. Is that a leak?: No. It identifies the project; security comes from rules and App Check. Treat it as public.
- Can AI write rules for me?: For first drafts yes. Always run this review on generated rules; they commonly use
request.auth != null(too loose). - How do I test rules without deploying?: Use the Firebase Emulator + the Rules Unit Testing SDK. These prompts cover the structural audit; the emulator covers behavior.
- What about Firebase Extensions?: Audit each extension’s service account scopes; they often have broad permissions. Add a row in template 5 for installed extensions.