Firebase : vos règles de sécurité laissent-elles tout passer ?

Le même principe que partout : le navigateur parle à la base

Avec Firebase, votre application lit et écrit dans la base directement depuis le navigateur. La configuration Firebase visible dans le code (apiKey, projectId…) n'est pas un secret : elle sert seulement à identifier votre projet. Ce qui protège vos données, ce sont les règles de sécurité, écrites dans la console Firebase, une série pour chaque service.

Le piège du « mode test »

À la création d'une base, Firebase propose un mode test qui ouvre tout, avec une date d'expiration à trente jours. Deux dérives sont fréquentes :

• quelqu'un repousse la date pour que l'application continue de fonctionner, encore et encore ;
• ou remplace la règle par une version sans date, ouverte pour toujours.

Vérification 1 : lire vos règles

Dans la console Firebase, ouvrez successivement Firestore Database, Realtime Database et Storage, puis leur onglet Règles. Signaux d'alarme :

allow read, write: if true;
allow read, write: if request.time < timestamp.date(2027, 1, 1);
".read": true,  ".write": true

• if true : tout le monde peut tout faire, sans compte ;
• une condition seulement sur une date : c'est le mode test, repoussé ;
• ".read": true en haut de la Realtime Database : toute la base est lisible.

Même if request.auth != null ne suffit souvent pas : n'importe qui peut créer un compte et devenir « connecté ». Une bonne règle compare l'utilisateur au propriétaire du document, par exemple request.auth.uid == resource.data.userId.

Vérification 2 : le simulateur

Dans l'onglet Règles de Firestore, le simulateur (Rules Playground) permet de tester une lecture ou une écriture sur un document précis, en tant que visiteur non connecté ou en tant qu'utilisateur donné. Testez au moins :

• la lecture d'un document client, sans être connecté : elle doit être refusée ;
• la lecture du document d'un autre client, connecté avec un compte ordinaire : refusée aussi ;
• la modification d'un champ sensible (rôle, solde, statut) par le client lui-même : refusée.

Vérification 3 : le test qui tranche

Sur votre propre projet, demandez à la base ce qu'elle répond à un inconnu. Pour Firestore, dans un terminal (remplacez le nom du projet et celui d'une collection) :

curl "https://firestore.googleapis.com/v1/projects/VOTRE-PROJET/databases/(default)/documents/clients?pageSize=3"

Pour la Realtime Database (copiez l'adresse exacte affichée en haut de l'onglet Données ; en Europe, elle se termine par firebasedatabase.app) :

curl "https://ADRESSE-DE-VOTRE-BASE/.json?shallow=true"

Une erreur de permission (PERMISSION_DENIED, Permission denied, codes 401 ou 403) : la donnée est protégée. Une réponse vide ({}) peut aussi venir d'une collection vide. Des documents ou une liste de clés : elle est lisible par n'importe qui sur Internet, aujourd'hui.

Vérification 4 : les fichiers

Les règles de Storage sont distinctes de celles de la base. Une base bien protégée avec un Storage en allow read, write: if true laisse lire et remplacer tous les fichiers déposés : photos, factures, pièces d'identité. Vérifiez-les avec le même soin (voir aussi notre guide Les fichiers déposés par vos utilisateurs sont-ils publics ?).

Si vous avez trouvé un problème

Réécrivez les règles collection par collection, en partant du principe « tout est refusé, sauf ce qui est explicitement permis ». Testez chaque règle dans le simulateur avant de la publier, puis refaites le test de la vérification 3. Activez aussi App Check, qui limite l'accès à votre base aux applications que vous avez publiées ; c'est une protection en plus des règles, jamais à leur place.

Ce que cette vérification ne couvre pas

Les fonctions serveur (Cloud Functions) et ce qu'elles autorisent, les clés d'administration (le compte de service Firebase ne doit jamais être dans le code de l'application), et la facturation : une base ouverte peut aussi être lue en masse, à vos frais. C'est ce que couvre notre diagnostic.