Schema drift happens when:

    User documents start with { name: "John", email: "john@..." }

    Later, someone adds { name: "Jane", email: "jane@...", profile: {...} }

    Even later: { name: "Bob", email: "bob@...", profile: "basic" }

Now profile is sometimes an object, sometimes a string, sometimes missing entirely.

When this breaks:

javascript// This works for some docs, fails for others user.profile.avatar // TypeError: Cannot read property 'avatar' of undefined

Security gaps emerge because:

    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.

The real problem: Firestore doesn't enforce schemas, and there's no built-in way to audit for these issues across your entire database.

I got burned by this enough times that I built an open-source CLI tool to scan for schema inconsistencies and security red flags:

npx lintbase scan firestore --key ./service-account.json

It samples your collections, flags type mismatches, and pattern-matches collection names against common sensitive data indicators.

GitHub: github.com/lintbase/lintbase

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?