Sécuriser ton app Firebase, sans être développeur

La clé apiKey de ta configuration Firebase est publique, et Firebase le dit lui-même. Ce qui protège tes données, ce sont tes règles de sécurité. Voici les six endroits où elles laissent passer, comment le voir toi-même, et ce que Rustine vérifie pour toi.

En bref

1. Des règles en if true

allow read, write: if true ouvre ta base à tout le monde, en lecture comme en écriture. Firebase le résume ainsi : n'importe qui peut écraser toute ta base. C'est aussi ce que donne le mode test.

Vérifie toi-même

Dans la console Firebase, ouvre l'onglet Règles de Firestore, de Realtime Database et de Storage. Cherche if true, et ".read": true ou ".write": true. Le Rules Playground te dit qui peut lire quoi.

Ce que Rustine vérifie

Sur GitHub, Rustine lit tes fichiers de règles et repère les if true. Sur ton site prouvé, l'audit complet voit l'effet : une base qui répond à un visiteur anonyme.

Code GitHub · Solo, ProAudit complet · Solo, Pro

Sources : [1]

2. Tout utilisateur connecté a tout

request.auth != null semble prudent, mais si l'inscription est ouverte, n'importe qui crée un compte et lit ou modifie toute ta base. Firebase le déconseille.

Vérifie toi-même

Dans tes règles, chaque accès doit comparer request.auth.uid au propriétaire de la donnée, pas seulement vérifier qu'un utilisateur est connecté.

Ce que Rustine vérifie

Sur GitHub, Rustine repère les règles qui ouvrent tout à n'importe quel utilisateur connecté.

Code GitHub · Solo, Pro

Sources : [1]

3. Une Realtime Database lisible

Une Realtime Database ouverte se lit d'un bloc depuis son adresse : tout l'arbre de données, d'un coup.

Vérifie toi-même

Dans l'onglet Règles de Realtime Database, ".read" ne doit pas valoir true à la racine. Donne l'accès branche par branche, à l'utilisateur concerné.

Ce que Rustine vérifie

Après preuve et confirmation que le projet est à toi, l'audit complet regarde si la base répond à un visiteur anonyme. Il ne lit que la liste des premières clés, jamais les données.

Audit complet · Solo, Pro

Sources : [1]

4. Un Storage qu'on peut lister

Si les règles de Storage laissent lire tout le monde, chaque fichier envoyé par tes utilisateurs devient public : photos, documents, exports.

Vérifie toi-même

Dans l'onglet Règles de Storage, pas de allow read: if true sans condition sur le chemin ou l'utilisateur.

Ce que Rustine vérifie

Après preuve et confirmation du projet, l'audit complet demande un seul nom de fichier pour savoir si la liste est ouverte. Sur GitHub, il lit aussi tes règles de Storage.

Audit complet · Solo, ProCode GitHub · Solo, Pro

Sources : [1]

5. Des collections Firestore ouvertes

Une collection lisible sans connexion, users ou orders par exemple, expose ses documents à quiconque connaît son nom. Et ce nom est souvent dans ton JavaScript.

Vérifie toi-même

Dans le Rules Playground, simule une lecture non authentifiée sur chacune de tes collections. Elle doit être refusée, sauf pour ce qui est vraiment public.

Ce que Rustine vérifie

Après preuve et confirmation du projet, l'audit complet essaie une lecture anonyme sur les collections nommées dans ton code, sans récupérer le contenu des documents.

Audit complet · Solo, Pro

Sources : [1]

6. Les vraies clés secrètes

La clé Firebase n'est pas un secret. Une clé de compte de service, une clé Stripe ou une clé Gemini, si. Dans ton app, elles se lisent.

Vérifie toi-même

Dans ton code, aucune clé privée de compte de service ni clé secrète d'un autre service. Elles vont côté serveur, dans Cloud Functions par exemple.

Ce que Rustine vérifie

Dès le scan gratuit, Rustine cherche les clés secrètes (Stripe, OpenAI, Anthropic, clés privées…) dans le JavaScript de ton site, et ignore la clé Firebase publique. Une clé Gemini a la même forme qu'une clé Firebase : vérifie-la toi-même. Sur GitHub, il lit tout ton code et son historique.

Scan gratuitCode GitHub · Solo, Pro

Sources : [2]

Questions

Sources

1. Firebase, Avoid insecure rules, consulté le 15/10/2026
2. Firebase, Learn about using and managing API keys for Firebase, consulté le 15/10/2026