Firebase Security Rules : ne laissez plus votre base de données ouverte

Refusez tout par défaut et accordez l’accès collection par collection. Ici, chaque utilisateur ne peut lire et écrire que son propre document dans users, et rien d’autre n’est accessible.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
    // Every other path is denied by default.
  }
}

Limitez les champs qu’un utilisateur peut modifier, pour qu’il ne puisse pas s’octroyer des privilèges ni altérer des données gérées par le serveur. affectedKeys().hasOnly() rejette toute mise à jour qui touche d’autres champs.

match /users/{userId} {
  allow update: if request.auth.uid == userId
    && request.resource.data.diff(resource.data)
         .affectedKeys().hasOnly(["displayName", "photoURL"]);
}

Cherchez dans vos règles les match /{document=**} combinés à un allow trop large, les if true et les horodatages d’expiration du mode test. N’oubliez pas que Cloud Storage et Realtime Database ont leurs propres fichiers de règles — verrouillez-les aussi.

Utilisez le Rules Playground de la console Firebase ou l’Emulator Suite avec @firebase/rules-unit-testing pour exécuter des lectures en tant qu’utilisateur non authentifié et en tant qu’autre utilisateur connecté. Une vérification externe rapide consiste à envoyer une requête REST non authentifiée : si elle renvoie des documents, la collection est publique.

curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/users"