Firebase Authentication est puissant et simple à intégrer, mais quelques erreurs récurrentes peuvent compromettre sécurité et performance. Voici 4 pièges que je rencontre souvent — et comment les éviter.

1️⃣ Règles Firestore trop permissives

Le piège : laisser le mode test ou request.auth != null partout.

La parade : moindre privilège, ownership, et rôles via custom claims.

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;
    }
  }
}

Teste tes règles avec Firebase Emulator et ajoute des conditions granulaires (ex. request.auth.token.email_verified si tu exiges un email vérifié).

2️⃣ Ne pas vérifier l'email (ou le téléphone)

Le piège : donner l'accès complet à des comptes non vérifiés.

La parade : activer la vérification et contrôler 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
  }
});

Vérification par 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);

3️⃣ Mettre des infos sensibles dans les tokens (et s'y fier côté client)

Le piège : stocker des rôles dans le token et faire confiance au client.

La parade : définir des custom claims côté serveur, vérifier côté serveur et rafraîchir le token côté client.

// 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
}

4️⃣ Mal gérer la session et la déconnexion

Le piège : un utilisateur désactivé peut continuer à accéder pendant la durée de vie du token (~1 h).

La parade : révoquer, écouter l'état, privilégier les sessions côté serveur.

// 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 Web, évite localStorage pour les ID tokens (XSS) — préfère des cookies httpOnly (Secure, SameSite) ou un coffre-fort natif (Capacitor Secure Storage) en mobile.

💡 Bonus sécurité

• App Check (reCAPTCHA Enterprise côté Web) pour protéger Firestore/Functions/Storage.
• MFA pour les comptes à privilèges.
• Logs & alertes : surveille échecs de connexion/inscriptions (Cloud Logging, Sentry).

🚀 En résumé : règles minimales et testées • e-mail/téléphone vérifiés • claims validés côté serveur • sessions maîtrisées (révocation, cookies sécurisés).

👉 Un audit ou une configuration Auth à faire ? Contactez-moi directement ici sur LinkedIn.