Firebase rules open to the public: how to tell and how to fix

Spot open Realtime Database, Firestore, and Storage rules, and lock them down with auth-based rules.

Classic Firebase footgun: rules that allow anyone to read or write. The Tea app's early breach was described as a Firebase database leak from broken authentication/authorization (Barracuda summary).

Dangerous patterns

// Realtime Database — never ship this
{ "rules": { ".read": true, ".write": true } }

// Firestore — equally bad
allow read, write: if true;

Safer baseline

// Realtime Database
{ "rules": {
  "users": {
    "$uid": {
      ".read": "auth != null && auth.uid == $uid",
      ".write": "auth != null && auth.uid == $uid"
    }
  }
} }

// Firestore
allow read, write: if request.auth != null
  && request.auth.uid == resource.data.ownerId;

Test with the Rules Playground and from a logged-out browser.

Rewrite Firebase security rules so no collection or path is world-readable or world-writable. Require request.auth != null (or auth != null for RTDB) and restrict each user to their own data. Show me the full rules file.

Related: Supabase RLS · Lovable security

More guides

• Is my Lovable app secure?
• How to enable Supabase Row Level Security (RLS)
• Exposed Supabase service_role key: what to do now
• Lovable security checklist