如何在 Firestore 中捕捉模式漂移和安全漏洞？
模式漂移发生在以下情况下：<p><pre><code> 用户文档开始时为 { name: "John", email: "john@..." }
后来，有人添加了 { name: "Jane", email: "jane@...", profile: {...} }
更晚的时候: { name: "Bob", email: "bob@...", profile: "basic" }
</code></pre>
现在，profile 有时是一个对象，有时是一个字符串，有时完全缺失。<p>当这导致问题时：<p>javascript// 对某些文档有效，但对其他文档无效
user.profile.avatar // TypeError: 无法读取未定义的属性 'avatar' <p>安全漏洞出现的原因是：<p><pre><code> 你编写规则时假设模式是一致的：允许读取：如果 resource.data.profile.role == "admin"
但当 profile 是字符串或缺失时，这条规则的行为就会变得不可预测（通常会抛出评估错误，阻止合法用户访问，或者更糟糕的是，如果规则过于宽松，则留下漏洞）。
集合在没有适当规则的情况下被添加（如 bankInfo、userSecrets 等）。
测试集合（debugUsers、tempData）在生产环境中保持开放访问。
</code></pre>
真正的问题是：Firestore 不强制执行模式，并且没有内置的方法来审计整个数据库中的这些问题。<p>我在这方面遭遇了足够多的麻烦，因此构建了一个开源 CLI 工具，用于扫描模式不一致性和安全隐患：<p>npx lintbase scan firestore --key ./service-account.json<p>它会抽样你的集合，标记类型不匹配，并将集合名称与常见敏感数据指标进行模式匹配。<p>GitHub: github.com/lintbase/lintbase<p>社区提问：你目前如何在 Firestore 项目中捕捉这些问题？手动审计？还是只是等待生产中的错误？
查看原文
Schema drift happens when:<p><pre><code> User documents start with { name: "John", email: "john@..." }
Later, someone adds { name: "Jane", email: "jane@...", profile: {...} }
Even later: { name: "Bob", email: "bob@...", profile: "basic" }
</code></pre>
Now profile is sometimes an object, sometimes a string, sometimes missing entirely.<p>When this breaks:<p>javascript// This works for some docs, fails for others
user.profile.avatar // TypeError: Cannot read property 'avatar' of undefined<p>Security gaps emerge because:<p><pre><code> You write rules assuming a consistent schema: allow read: if resource.data.profile.role == "admin"
But when profile is a string or missing, this rule behaves unexpectedly (usually throwing evaluation errors and blocking access for legitimate users, or worse, leaving loopholes if rules are overly permissive).
Collections get added without proper rules (bankInfo, userSecrets, etc.)
Test collections (debugUsers, tempData) stay in production with open access.
</code></pre>
The real problem: Firestore doesn't enforce schemas, and there's no built-in way to audit for these issues across your entire database.<p>I got burned by this enough times that I built an open-source CLI tool to scan for schema inconsistencies and security red flags:<p>npx lintbase scan firestore --key ./service-account.json<p>It samples your collections, flags type mismatches, and pattern-matches collection names against common sensitive data indicators.<p>GitHub: github.com/lintbase/lintbase<p>Question for the community: How do you currently catch these issues in your Firestore projects? Manual audits? Or do you just wait for production bugs?