Audit des règles Firebase Firestore : cadrer une application mobile avant sa mise en ligne

Listez les collections et les parcours qui manipulent des données sensibles : profil, équipe, commandes, documents, abonnements ou contenus privés. Pour chaque opération, précisez qui doit y accéder : visiteur, propriétaire, membre d'une organisation, administrateur ou service serveur. Une règle ne peut être jugée sans ce contrat métier.

Prévoyez au moins les cas opposés : un utilisateur accède à ses données, un autre utilisateur ne le peut pas, et un membre d'une organisation ne peut pas lire celle d'une autre. Si des comptes anonymes existent, décrivez aussi ce qu'ils peuvent faire avant et après la connexion.

La documentation Firebase recommande des tests de règles avec l'Emulator Suite. Un audit utile vérifie les lectures et écritures autorisées, mais également les refus : document d'un autre utilisateur, changement de rôle, champs interdits ou suppression non prévue. Les requêtes de l'application doivent être testées avec les mêmes identités et chemins que dans le produit.

Le livrable attendu est un jeu de scénarios reproductibles, avec les règles examinées, les écarts constatés et les corrections proposées. Une simple capture de la console Firebase ou un test manuel « ça marche » ne démontre pas l'isolation des données.

Si l'application charge des pièces jointes, inspectez aussi les règles Cloud Storage : lecture, dépôt, taille, type de fichier et propriété du chemin. Les règles Firestore ne protègent pas automatiquement les fichiers.

Examinez séparément les Cloud Functions, les appels serveur et les comptes de service. Firebase précise que ses bibliothèques serveur contournent les règles Firestore et utilisent les autorisations IAM. Une fonction qui reçoit un identifiant de document doit donc vérifier elle-même que l'appelant a le droit d'agir.

Pour chiffrer l'audit, fournissez la structure des données, les fichiers de règles, les principaux parcours, la liste des rôles et les environnements disponibles. Donnez un accès nominatif limité au projet ; évitez de transmettre des identifiants partagés ou une copie de données de production sans nécessité.

Demandez un rapport qui distingue les accès non autorisés démontrés, les zones non testées et les améliorations de défense. La correction doit inclure des tests de non-régression et un contrôle des parcours légitimes : fermer une faille en bloquant tous les clients n'est pas une livraison exploitable. Le périmètre et le prix dépendent alors des chemins, rôles et services réellement concernés.