900 Sites, 125M accounts, 1 Vulnerability

Original Article ↗ Hacker News Discussion ↗

Firebase’s Security Model & Its Pitfalls

  • Many see Firebase’s security rules as conceptually sound but hard to use correctly in practice, especially for Realtime Database.
  • Rules are “set and forget”: new fields/collections often inherit overly-permissive rules when business logic changes.
  • Security issues arise from:
    • Novel rule-based model compared to traditional backends.
    • Ease of mass scanning when many apps use the same platform.
    • Insecure defaults / “allow by default” patterns and devs just using read/write true to make things work.
  • UX criticism: most of Firebase is polished UI, but rules are a plain config file that many newer devs avoid touching properly.

Google Support and Organizational Issues

  • Multiple comments describe Firebase/Google support as unresponsive and heavily outsourced.
  • There is a sense that Google underinvests in human-centric, high-skill support for developer products.
  • Some argue this “bot-first, human-last” culture may hurt Google long-term; others think regulation or simple inertia matter more.

Architecture: Direct Frontend DB Access

  • Many are uneasy with frontends writing directly to a database, even with rules:
    • Harder to ensure validation, content checks, and evolving privacy requirements.
    • Larger “surface area to forget” compared to a more centralized backend.
  • Defenders say it works for simple “user-only data” apps (e.g., notes/sync) and that mature projects often move writes to Cloud Functions or traditional servers, keeping reads client-side.

Mitigations and Best Practices

  • Suggestions include:
    • Template-based “simple security modes” and mandatory rule tests.
    • Treat each collection as having a clear security profile (public, per-user, admin-only) and never mix sensitivities.
    • Default-deny transpilers that force explicit rules for new fields.
    • Better audit logs and notifications for implicit schema changes.
    • RLS-like mechanisms (as in Postgres/Supabase) to express auth in a familiar language.

Impact, Ethics, and User Security

  • Many vulnerable sites remain unfixed despite disclosure attempts; emails often ignored, and dashboards rarely checked.
  • Debate over publishing a list of affected sites: could help users but also aid attackers.
  • Broader concern that low-bar cloud tools enable organizations with little security competence to collect large volumes of PII.
  • Users are advised to use password managers and unique/aliased emails to limit damage from inevitable breaches.