Firebase est pratique parce qu'il connecte ton appli à une base de données sans backend, mais cette commodité est aussi le piège : la sécurité dépend presque entièrement des règles que tu écris. Voici les erreurs qui reviennent le plus.
Laisser les règles en mode test
Quand tu crées Firestore ou Realtime Database, Firebase propose un mode test qui laisse tout le monde lire et écrire pendant un temps. C'est commode pour démarrer, mais beaucoup de gens lancent avec ces règles encore en place. Résultat : n'importe qui peut lire et modifier toute ta base de données depuis la console du navigateur.
Avant de lancer, change les règles pour exiger une authentification et limiter chaque utilisateur à ses propres données.
Confondre la clé publique avec la sécurité
La config Firebase que tu colles dans le frontend (apiKey, projectId, etc.) est publique par conception et n'est pas un secret. Ça déroute beaucoup de gens : ils supposent que parce qu'elle vit dans le client, Google la protège. Ce n'est pas le cas. Ce qui protège tes données, ce sont les règles de sécurité, pas le fait de cacher cette clé. Supposer le contraire mène à des bases de données ouvertes.
Des règles qui autorisent tout lire
Une règle comme allow read: if true laisse tes collections ouvertes à n'importe qui. L'erreur classique est de desserrer les règles jusqu'à ce que l'appli cesse de renvoyer des erreurs, puis de ne jamais les resserrer. Écris des règles par collection : vérifie request.auth et compare l'utilisateur au propriétaire du document.
Des données sensibles dans des documents lisibles
Même si tu exiges un login, revois ce que tu stockes. Des emails, des rôles admin ou des drapeaux internes dans des documents que tout utilisateur authentifié peut lire restent une fuite. Sépare le privé dans des collections aux règles plus strictes et ne suppose pas que personne ne regardera.
D'autres clés cachées dans le bundle
La config Firebase est publique, mais elle voyage souvent avec d'autres clés qui ne le sont pas : jetons pour les services de paiement, d'email ou d'IA. Celles-là sont secrètes et ne doivent pas finir dans le JavaScript du navigateur. L'IA les intègre parfois pour faire marcher quelque chose sur le moment.
Scanaris repère ce qui a été exposé
Scanaris fait des contrôles en lecture seule sur ton site publié : il cherche les clés et secrets exposés dans le frontend, les fichiers sensibles accessibles et les réglages d'en-têtes faibles. Il n'exploite rien ; il regarde seulement ce qui est déjà public et te prévient. Chaque trouvaille vient avec un prompt pour la corriger dans ton IA. Scanne ton appli avant que quelqu'un d'autre ne le fasse.