Firebase Auth : 4 pièges courants (et les parades)

Firebase Auth est une bonne base pour démarrer vite, surtout sur un portail, un extranet, une application métier ou un espace client. Le problème n’est pas l’outil, mais la façon dont on lui délègue trop vite la confiance : permissions trop larges, comptes non vérifiés, rôles mal gérés et sessions trop confiantes.

Dans la vraie vie, les ennuis arrivent rarement au moment du premier prototype. Ils apparaissent quand l’application commence à porter des données réelles, des rôles, des parcours sensibles et des usages plus variés que prévu.

Le bon réflexe n’est donc pas seulement de “brancher Firebase Auth”, mais de cadrer clairement où se décide la confiance : dans les règles Firestore, dans le back-end, dans les claims, dans la vérification du compte et dans la durée de session acceptée.

Décrire le contexte d’authentification

Avant de corriger : savoir où la confiance se décide

Le problème principal avec Firebase Auth n’est pas l’écran de connexion. C’est la frontière entre ce que l’utilisateur voit, ce que le client croit, ce que les règles autorisent et ce que le serveur accepte réellement.

• qui peut lire quelles données, et sur quel critère précis ;
• quand un compte est réellement considéré comme vérifié ;
• où sont définis les rôles et qui peut les changer ;
• comment une révocation ou une désactivation coupe l’accès côté utilisateur ;
• où se trouve la vérité métier : interface, règles, back-end ou combinaison des trois.

1. Règles Firestore trop permissives

C’est l’erreur la plus dangereuse et pourtant l’une des plus fréquentes. Laisser le mode test, ou poser un simple request.auth != null partout, revient à dire qu’un compte connecté vaut automatiquement autorisation large.

Dans un petit prototype, cela peut sembler acceptable quelques jours. En production, cela ouvre vite la porte à des lectures trop larges, des écritures non prévues ou des effets de bord difficiles à voir avant incident.

Ce qu’il faut viser : moindre privilège, ownership explicite, rôles cadrés et règles testées.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Chaque user ne lit/écrit que son propre document
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }

    // Exemple de rôle admin via custom claim
    match /projects/{projectId} {
      allow read:  if request.auth != null;
      allow write: if request.auth.token.admin == true;
    }
  }
}

Le bon niveau de contrôle ne consiste pas seulement à vérifier qu’un utilisateur est connecté. Il faut vérifier qu’il est le bon utilisateur, sur la bonne ressource, pour la bonne action.

2. Ne pas vérifier l’e-mail ou le téléphone avant d’ouvrir l’usage

Un compte créé n’est pas forcément un compte fiable. Si l’e-mail n’est pas vérifié, ou si la logique téléphone est mal cadrée, l’application peut donner un accès trop large à des comptes encore incertains.

Le sujet n’est pas uniquement de “faire joli” avec une étape de confirmation. Il s’agit de savoir quand un compte mérite réellement l’ouverture de certaines zones, et quand il faut rester sur un accès limité.

Exemple de contrôle côté client

// SDK modulaire v9+
import { getAuth, onAuthStateChanged } from 'firebase/auth';

const auth = getAuth();
onAuthStateChanged(auth, (user) => {
  if (user?.emailVerified) {
    // Accès autorisé
  } else {
    // Demander la vérification / limiter certaines features
  }
});

Exemple côté téléphone

import { getAuth, RecaptchaVerifier, signInWithPhoneNumber } from 'firebase/auth';

const auth = getAuth();
const verifier = new RecaptchaVerifier(auth, 'recaptcha-container', { size: 'invisible' });

const confirmation = await signInWithPhoneNumber(auth, '+33...', verifier);
const credential  = await confirmation.confirm(code);

Le client peut adapter le parcours, mais si certaines données ou actions sont sensibles, le contrôle final doit rester cohérent avec les règles et, si besoin, avec le back-end.

3. Mal gérer les rôles et les claims

Le rôle “admin” dans l’interface n’a aucune valeur s’il n’est pas réellement défini côté serveur. Le client peut lire un token et adapter l’affichage, mais il ne doit jamais devenir la source de vérité pour des permissions métier.

Le bon usage des custom claims consiste à les définir côté serveur, à s’en servir pour l’interface si besoin, puis à faire contrôler les accès sensibles là où la confiance est justifiée.

// Admin SDK (serveur)
await admin.auth().setCustomUserClaims(uid, { admin: true });

// Client : forcer le refresh pour récupérer les nouveaux claims
import { getIdTokenResult } from 'firebase/auth';
const result = await getIdTokenResult(user, true);
if (result.claims.admin) {
  // Autoriser l'accès admin
}

Un token peut aider à afficher le bon menu ou le bon écran. Il ne doit pas être le seul garde-fou qui protège une ressource métier sensible.

4. Trop faire confiance à la session en cours

Un compte désactivé, un rôle retiré ou un accès révoqué ne disparaît pas instantanément partout si la session n’est pas gérée correctement. C’est là que des écarts discrets apparaissent : utilisateur encore connecté, droits encore visibles, écran encore utilisable alors qu’il ne devrait plus l’être.

Firebase Auth fournit les briques de révocation, mais encore faut-il les intégrer proprement au parcours réel.

// Admin SDK : révoquer tous les refresh tokens d'un user
await admin.auth().revokeRefreshTokens(uid);

import { getAuth, onIdTokenChanged, signOut } from 'firebase/auth';

const auth = getAuth();
onIdTokenChanged(auth, async (user) => {
  // Exemple : si vous mettez claims.active = false côté serveur
  if (user) {
    const t = await user.getIdTokenResult();
    if (t && t.claims.active === false) {
      await signOut(auth);
    }
  }
});

Sur le web, mieux vaut éviter de laisser des tokens dans localStorage dès qu’un sujet XSS devient crédible. Sur mobile, il faut aussi choisir un stockage cohérent avec le niveau de risque, pas juste le plus rapide à brancher.

Compléments utiles quand le niveau d’exigence monte

• App Check pour limiter certains usages abusifs côté client ;
• MFA pour les comptes à privilèges ou les contextes plus sensibles ;
• logs et alertes pour surveiller échecs, créations de comptes et comportements anormaux ;
• émulateur Firebase pour tester réellement les règles avant mise en ligne.

Ordre de correction conseillé en pratique

1. vérifier d’abord que les règles Firestore n’ouvrent pas trop large ;
2. cadrer ensuite la vérification du compte avant l’accès réel aux données ;
3. mettre les rôles et claims sous contrôle serveur ;
4. gérer la révocation et la fin de session de manière visible et fiable ;
5. tester les cas limites : compte non vérifié, rôle retiré, utilisateur désactivé, ressource non autorisée.

Quand Firebase Auth suffit et quand il faut élargir l’architecture

Réponse courte

Firebase Auth peut très bien faire le travail, à condition de ne pas lui demander implicitement de régler à lui seul la sécurité d’un produit. Les vrais garde-fous restent dans les règles, dans les rôles, dans la session et dans le niveau de confiance accordé au client.

Sur un portail, un extranet ou une application métier, la bonne approche consiste à traiter l’authentification comme une brique parmi d’autres, pas comme un raccourci qui dispense de penser l’autorisation.

Aller plus loin

Articles liés