Firebase est le backend préféré de beaucoup d'applis construites avec l'IA : Lovable, Bolt ou Cursor le branchent en quelques minutes et tu as l'authentification, la base de données et les fichiers sans monter de serveur. Le problème, c'est que son modèle de sécurité est l'inverse de celui d'un backend traditionnel. Ici, le navigateur parle directement à la base de données, donc il n'y a pas de serveur qui filtre les requêtes : les règles de sécurité sont ta seule barrière, et une règle mal écrite laisse toutes les données à la vue de tous. Ce guide passe en revue les dix erreurs les plus fréquentes, avec la mauvaise règle et la bonne dans chaque cas, et se termine par comment le vérifier toi-même.
1. Les règles en mode test, ou ce qui vient après
Quand tu crées une base de données, Firebase te propose le « mode test » : tout ouvert pendant trente jours. La règle ressemble à ça :
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 11, 3);
}
}
}Jusqu'à cette date, n'importe qui avec ton projectId (qui est dans le code du navigateur) peut lire et écrire toute la base de données. Et le pire vient après : à l'expiration, l'appli cesse de fonctionner, le développeur cherche une solution rapide et remplace la date par if true. Maintenant, le trou est permanent. La solution, c'est d'écrire des règles par collection dès le premier jour, basées sur qui est l'utilisateur et à qui appartient le document.
2. allow read: if true sur des données d'utilisateurs
Il y a des collections qui peuvent être publiques (un catalogue de produits, les articles d'un blog). Mais allow read: if true sur users, orders ou messages signifie que n'importe qui peut télécharger la liste complète. La bonne façon de protéger des documents par utilisateur :
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}Chaque utilisateur lit et écrit seulement son document. Pour des données partagées entre plusieurs (une équipe, un projet), stocke la liste des membres dans le document et vérifie-la dans la règle.
3. Confondre « authentifié » et « autorisé »
La règle allow read: if request.auth != null a l'air sûre et c'est l'erreur la plus courante. Elle dit : n'importe quel utilisateur connecté peut lire. Mais s'inscrire sur ton appli est gratuit et prend dix secondes, donc en pratique c'est la même chose qu'ouvert. Authentifié répond à qui tu es ; autorisé, à ce que tu peux voir. Les règles doivent répondre à la seconde question.
4. Des données sensibles dans des documents lisibles
Un profil public avec nom et avatar, c'est raisonnable. Le même document avec e-mail, téléphone, adresse et un jeton d'accès, non. Si d'autres utilisateurs doivent pouvoir voir une partie du profil, sépare le public du privé en deux documents ou dans une sous-collection private avec des règles plus strictes. Ce qui n'est pas dans un document lisible ne peut pas fuiter.
5. Croire que la configuration Firebase est un secret
L'objet avec apiKey, authDomain et projectId va dans le navigateur par conception : il identifie ton projet, il n'autorise rien. Le voir dans le code source n'est pas une faille, et ce n'est pas ce qu'il faut cacher. Ce qu'il faut faire avec cette clé, c'est la restreindre dans la console Google Cloud aux domaines de ton site (restriction par référent HTTP) et activer App Check, qui exige que les requêtes viennent de ta vraie appli et pas d'un script.
6. Les autres clés, elles, sont secrètes
L'erreur grave est ailleurs : à côté de la configuration Firebase, le bundle embarque la clé secrète de Stripe, celle d'OpenAI ou celle d'un service d'e-mail parce que « c'était plus simple comme ça ». Ces clés donnent accès à de l'argent et à des comptes tiers. Leur place, c'est une Cloud Function avec les secrets dans des variables d'environnement, et le navigateur appelle la fonction, jamais le service directement. Le détail est dans les secrets que ton appli laisse fuiter dans le navigateur.
7. Storage sans règles propres
Cloud Storage a ses propres règles et on les oublie souvent. Avec allow read, write: if request.auth != null, n'importe quel utilisateur inscrit peut lire les fichiers des autres, téléverser ce qu'il veut vers n'importe quel chemin et remplir ton quota. Une règle raisonnable limite le chemin à l'utilisateur et valide la taille et le type :
match /users/{userId}/{fileName} {
allow read: if request.auth != null && request.auth.uid == userId;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}8. Realtime Database ouverte
Si tu utilises la base de données temps réel à la place de Firestore, l'équivalent est ".read": true à la racine. Les règles sont un autre langage, mais la logique est la même : rien d'ouvert à la racine, et des permissions par branche avec auth.uid.
9. Écrire sans valider
Permettre l'écriture au propriétaire du document ne suffit pas si tu ne valides pas ce qu'il écrit. Un utilisateur peut ajouter isAdmin: true ou plan: "pro" à son propre profil depuis la console du navigateur. Valide les champs avec request.resource.data : quelles clés existent, de quel type elles sont et que les champs sensibles ne changent pas.
allow update: if request.auth.uid == userId
&& !request.resource.data.diff(resource.data).affectedKeys()
.hasAny(['isAdmin', 'plan', 'credits']);10. Oublier la facture
Firebase facture à la lecture. Une règle qui permet list sans limite sur une grande collection laisse un script lire des millions de documents et te générer une facture inattendue. Limite les requêtes depuis les règles (request.query.limit <= 100), active App Check et mets des alertes de budget dans Google Cloud.
Comment le vérifier toi-même
- Simulateur de règles. Dans la console Firebase, onglet Règles, il y a un simulateur où tu testes une lecture en tant qu'utilisateur anonyme ou avec un UID précis. Essaie de lire
userssans session : ça doit être refusé. - Émulateur avec tests. L'émulateur local permet d'écrire des tests automatiques de règles. C'est la seule façon de ne pas les casser en les modifiant.
- De l'extérieur, sans jeton. L'API REST de Firestore répond à n'importe qui :
curl "https://firestore.googleapis.com/v1/projects/TON_PROJET/databases/(default)/documents/users"Si elle renvoie des documents, cette collection est ouverte. Si elle renvoie une erreur de permissions, la règle fonctionne. Répète avec chaque collection que tu as.
Scanaris vérifie ton Firebase de l'extérieur
Scanaris détecte la configuration Firebase dans ton bundle, vérifie si les collections habituelles répondent sans authentification, cherche d'autres clés qui ne devraient pas être dans le navigateur et contrôle les en-têtes, CORS et les fichiers exposés. Pour chaque constat, il te donne un fix prompt avec la règle ou le changement exact à coller dans Lovable, Bolt ou Cursor. Ce sont des vérifications en lecture seule sur ce qui est déjà public. La liste complète des risques est dans le guide de sécurité pour Firebase, et avant de lancer, il vaut la peine de repasser la checklist de sécurité.
Questions fréquentes
C'est un problème que mon apiKey Firebase soit dans le code ?
Pas en soi : elle identifie le projet, elle ne donne pas de permissions. Ce qui protège les données, ce sont les règles. Cela dit, restreins la clé à tes domaines et active App Check pour éviter les abus.
Que faire si mes règles sont ouvertes en ce moment ?
Ferme d'abord : mets des règles par collection avec request.auth.uid même si une fonctionnalité casse, et corrige l'appli ensuite. Puis vérifie dans les journaux d'utilisation s'il y a eu des lectures anormales et, si des données personnelles étaient exposées, demande-toi si tu dois le notifier.
Puis-je demander à mon IA d'écrire les règles ?
Oui, et elle le fait généralement bien si tu lui donnes la structure de tes collections et qui doit voir quoi. Mais teste-les dans le simulateur avant de publier : une IA écrit aussi if request.auth != null en croyant que c'est sûr.