Adoption du MFA dans les SaaS : failles et tests en 2026

Faille n° 1 : pas de MFA du tout

Sans second facteur, la sécurité du compte repose entièrement sur le mot de passe. Les attaquants n’ont pas besoin de le deviner : ils rejouent des listes d’identifiants issus d’autres fuites (credential stuffing) ou récupèrent des mots de passe et des cookies sur des postes infectés par des infostealers.

Les défauts qui accompagnent presque toujours l’absence de MFA aggravent le problème :

• pas de limitation de débit sur l’endpoint de connexion, ce qui permet de tester des milliers de combinaisons ;
• réponses différentes selon que l’e-mail existe ou non, ce qui permet d’abord de trier les comptes valides (voir l’énumération d’utilisateurs) ;
• sessions très longues, sans révocation possible ;
• aucune alerte sur une connexion depuis un nouveau pays ou un nouvel appareil.

Le compte le plus exposé est celui de l’administrateur client : il voit tous les salariés de l’entreprise.

Faille n° 2 : un MFA présent mais contournable

Ajouter un écran « saisissez votre code » ne suffit pas. Les contournements les plus fréquents en test :

1. MFA vérifié uniquement côté interface. Le serveur délivre un jeton de session complet dès la validation du mot de passe ; l’écran du code est une simple étape du front. En appelant l’API directement avec ce jeton, on ignore le second facteur.
2. Code sans limite d’essais. Un code TOTP à six chiffres sans limitation de tentatives se force en quelques heures.
3. Parcours de récupération sans MFA. La réinitialisation du mot de passe ouvre une session complète sans redemander le second facteur. Nous détaillons ces pièges dans les 7 erreurs de réinitialisation de mot de passe.
4. Désactivation ou réenrôlement sans revérification. Depuis une session volée, l’attaquant désactive le MFA ou ajoute son propre appareil sans ressaisir de code.
5. Jetons d’API et clés personnelles hors MFA. Une clé d’API créée depuis le compte donne un accès permanent qui n’est jamais soumis au second facteur.
6. SSO mal articulé. Le MFA est exigé sur le login local mais pas sur un second chemin (lien magique, ancien endpoint, application mobile).

Comment le tester

Utilisez un compte de test avec MFA activé, un proxy d’interception (Burp, Caido ou les outils du navigateur) et un environnement de préproduction :

1. Jeton avant code. Connectez-vous avec le mot de passe, arrêtez-vous à l’écran du code. Récupérez le jeton ou le cookie reçu à ce stade et appelez un endpoint protégé (GET /api/me, liste des salariés). S’il répond, le MFA est décoratif.
2. Niveau d’assurance. Sur Supabase, décodez le JWT et vérifiez le champ aal : aal1 après le mot de passe, aal2 après le code. Vérifiez ensuite que vos politiques RLS ou votre API exigent aal2 pour les données sensibles.
3. Force brute du code. Envoyez 20 codes faux de suite. Le serveur doit bloquer ou ralentir nettement.
4. Récupération. Réinitialisez le mot de passe et observez si la session obtenue contourne le code.
5. Gestion du facteur. Depuis une session active, tentez de désactiver le MFA ou d’ajouter un appareil sans ressaisir de code.
6. Chemins secondaires. Listez tous les moyens d’obtenir une session : lien magique, application mobile, SSO, clé d’API, ancienne version de l’API. Le MFA doit s’appliquer à chacun.
7. Connexion. Testez 50 mots de passe faux sur un compte : verrouillage, délai ou captcha doivent intervenir, et la réponse doit être identique pour un e-mail inexistant.

Comment corriger

• Vérifiez le second facteur côté serveur. Un jeton émis avant le code doit être limité à l’étape de vérification. Sur Supabase, exigez aal2 dans les politiques des tables sensibles.
• Rendez le MFA obligatoire pour les administrateurs et pour tout compte qui voit des données d’autres utilisateurs. Proposez-le à tous.
• Préférez les passkeys (WebAuthn), résistantes au phishing, au TOTP, et le TOTP au SMS.
• Limitez les essais sur le mot de passe et sur le code.
• Redemandez le facteur pour les actions sensibles : changement d’e-mail, désactivation du MFA, création de clé d’API, export massif.
• Révoquez les sessions au changement de mot de passe et réduisez leur durée (voir l’expiration des JWT).

Ce que ça change quand un agent IA agit avec le compte

Un agent IA intégré au produit ou branché par un utilisateur agit avec un jeton ou une clé d’API. Ce jeton a été obtenu une fois, puis il est réutilisé sans second facteur pour chaque action. Si l’agent peut exporter des données, modifier un RIB ou inviter un utilisateur, ces actions sensibles échappent au MFA que vous avez mis sur l’interface.

Le risque concret : une injection de prompt cachée dans un document ou un e-mail lu par l’agent déclenche une action que l’utilisateur n’aurait jamais validée, et aucun facteur n’est redemandé. La parade est la même que pour un humain : une confirmation explicite, hors du modèle, pour les actions à fort impact, et des jetons d’agent limités au strict nécessaire.

Vérifier qu’un agent ne peut pas contourner vos contrôles d’authentification fait partie du Red Team Agent Express, en cinq jours et avec des preuves.