“审一下我的 Firebase”只会得到 console 里看得见的提示。真正的 Firebase 配置 bug 藏在缝隙里：Storage rule 允许任何登录用户读、Cloud Function 公开 HTTP 触发器没接 App Check、缺一个复合索引线上才发现。下面 15 个 Prompt 各打一个 Firebase 面。
适合哪些场景
发 Firebase 后端的独立开发者、审 rule 改动的 reviewer、准备应对流量峰值的创业者、审 Cloud Functions 的安全同学。
什么时候不建议这样写 Prompt
只用 Firebase Analytics / Remote Config 的应用别用。这套是面向 Firestore / RTDB / Storage / Functions / Auth 的。
Prompt 结构公式
每个 Firebase 配置审计 Prompt 都要带这六个要素：
- 角色：让 AI 扮演谁（架构师 / SRE / QA Lead / Release Captain）。
- 上下文：仓库 / 框架 / 运行时版本 / 涉及哪些文件或 diff。
- 目标：一个具体可交付物——review 笔记、计划、checklist、测试文件、交接文档。
- 限制：AI 不能做什么（别重写、别自动 format、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可直接运行的代码。
- 示例 / 信号：1-2 条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 上线前 Firebase 配置 review
- Cloud Functions 部署审计
- Firestore 索引与查询计划检查
- Storage 桶公开访问审计
- App Check 与防刷 review
15 个可直接复制的 Prompt 模板
1. Firestore rules 覆盖审计
第一个跑——大多数 Firebase 泄漏在 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 `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 审计
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 复合索引审计
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 触发器审计
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 输入校验 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 覆盖审计
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 配置 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 与 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 与 Admin SDK 审计
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 数据校验 rules 审计
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 成本与冷启动 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. 环境与密钥 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. 多环境隔离审计
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.可替换变量： projects —— 例如 my-app-dev, my-app-staging, my-app-prod
15. Firebase 发现 → 迁移计划
最后跑——把发现转成部署序列。
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.容易踩的坑
allow read, write: if request.auth != null——任何登录用户全读到，几乎一定错。- 付费功能的 callable function 不接 App Check——刷接口的面巨大。
- 客户端能设置的 custom claim——只有 Admin SDK 能设。
- 查询先上、索引后上——第一个生产请求就挂。
- Firestore trigger 递归无深度保护——账单爆。
- Service Account JSON 提交进 repo——整个项目被接管。
- dev / prod project id 混在共享代码路径里——意外写生产。
优化技巧
- 永远先跑 rules 审计（模板 1-3）——这里漏了，其他审计都没意义。
- 用 Firebase Emulator Suite 拿 fixture 数据 dry-run 规则改动，配合这套 Prompt。
- 强制要 Firestore rule 用
request.resource.data.keys()约束——便宜又防字段意外。 - 每个 callable function review 都配 App Check 检查。
- 把
firestore.indexes.json和*.rules快照存到/firebase/baseline/，PR 前 diff。 - 成本 review 配 billing export 到 BigQuery——静态审看不到真实金额。
- 每次 Firebase 产品升级后重跑——默认值偶尔会变。
FAQ
- 和 Supabase RLS review 啥区别？: Firebase 面比 DB rule 多得多——Storage、Functions、Auth、App Check、Hosting——而且规则语言不同。Supabase 那篇是 Postgres 风味。
- 每个 PR 都跑吗？: 只对动
*.rules、firestore.indexes.json、functions/、Auth 配置的 PR 跑。其他 PR 不用。 - 客户端 Firebase apiKey 在源码里算泄漏吗？: 不算。它只标识项目，安全靠 rules 和 App Check。当公开处理。
- AI 能直接写 rules 吗？: 初稿可以。生成的 rules 一定跑这套 review——常用
request.auth != null（太松）。 - 不部署怎么测 rules？: 用 Firebase Emulator + Rules Unit Testing SDK。Prompt 覆盖结构审计；emulator 覆盖行为。
- Firebase Extensions 呢？: 审每个 extension 的 service account 权限——往往很大。在模板 5 加一行覆盖。