900 Sites, 125M accounts, 1 Vulnerability

Original Article ↗ Hacker News Discussion ↗

A large-scale exposure of user data from misconfigured Firebase/Firestore backends has renewed scrutiny of Google’s “database directly from the frontend” model and its security rules system. Commenters argue that while the rules engine is conceptually sound, insecure defaults, poor tooling, weak support, and inexperienced teams make it easy to ship apps where anyone can read or write sensitive data. Many advocate for stricter templates, better auditing and testing, or pushing more logic to traditional backends or row-level–secured databases like Postgres to reduce the blast radius of inevitable mistakes.

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.