Firebase Firestore : pourquoi 'allow read, write: if request.auth != null' n'est pas une sécurité
> En bref : La règle d'authentification basique de Firestore ne protège pas vos données. Voici pourquoi et comment corriger.
Le faux sentiment de sécurité
La règle allow read, write: if request.auth != null est la configuration Firestore la plus courante. Elle semble sécurisée : seuls les utilisateurs authentifiés ont accès. En réalité, elle permet à N'IMPORTE QUEL utilisateur authentifié de lire et modifier les données de TOUS les autres.
Le problème concret
Un utilisateur A se connecte. Il peut lire les documents de l'utilisateur B, modifier ses données, supprimer son compte. Parce que la règle vérifie seulement "est-ce que quelqu'un est connecté" : pas "est-ce le bon propriétaire".
La correction
Remplacez par : allow read, write: if request.auth.uid == resource.data.userId : vérifie que l'utilisateur connecté est bien le propriétaire du document.
Supabase vs Firebase sur ce point
Supabase utilise des politiques RLS au niveau PostgreSQL : plus granulaires mais avec leurs propres pièges (voir notre article sur les 5 erreurs Supabase RLS).
Ce que nous trouvons en audit
Sur les applications Firebase que nous auditons, 70% utilisent cette règle basique. Résultat : accès cross-utilisateur total pour tout utilisateur authentifié.
À retenir
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Réinitialisation de mot de passe : les 7 erreurs qui ouvrent vos comptes
Le flow « mot de passe oublié » est la porte d'entrée préférée des attaquants sur les SaaS : tokens prévisibles, liens sans expiration, host header injection. Les 7 erreurs que nous trouvons le plus souvent en audit.
WordPress REST API : les 7 endpoints dangereux activés par défaut
Votre WordPress expose des données sensibles via la REST API sans que vous le sachiez. Voici les 7 endpoints à vérifier immédiatement.
Laravel : quand Ziggy expose la carte complète de votre application
L'exposition des routes Ziggy et de la configuration Laravel donne aux attaquants une cartographie complète de votre app.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.