Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

API2 Broken Authentication

devsecops

Définition

API2 Broken Authentication est le deuxième risque de l'OWASP API Security Top 10, désignant les vulnérabilités dans les mécanismes d'authentification des APIs qui permettent à des attaquants de compromettre des tokens d'authentification, de s'approprier des identités, ou d'accéder à des fonctionnalités sans authentification valide. Ces failles surviennent quand les développeurs implémentent des systèmes d'authentification insuffisamment robustes ou utilisent des mécanismes obsolètes. Les manifestations les plus courantes de l'API2 incluent des tokens JWT avec des algorithmes faibles ou sans validation de l'expiration (claim "exp" non vérifié), l'absence de rotation des tokens après changement de mot de passe ou déconnexion, des API keys transmises en clair dans les URLs (apparaissant dans les logs de serveur), des tokens Bearer de longue durée sans mécanisme de révocation, l'acceptation de multiple formats d'authentification permettant de contourner les contrôles stricts, et l'absence de limitation des tentatives d'authentification facilitant le brute force. La remédiation de l'API2 requiert une approche défensive multicouche : utiliser des frameworks d'authentification éprouvés plutôt que des implémentations maison, des tokens à courte durée de vie avec refresh token révocable, TLS obligatoire pour toutes les communications, la validation complète des tokens JWT (signature, expiration, issuer, audience), et un rate limiting strict sur les endpoints d'authentification.

Vulnérabilités d'authentification API les plus répandues

Les failles API2 les plus courantes : JWT sans vérification de l'expiration (claim exp ignoré), tokens transmis dans les query parameters (visibles dans les logs), absence de révocation après logout (stateless sans blacklist), credential stuffing facilité par l'absence de rate limiting sur /auth/token, et Basic Auth sans TLS (credentials en Base64 lisible). Chacune de ces failles permet à un attaquant de maintenir un accès illégitime ou d'usurper une identité.

Implémentation sécurisée de l'authentification API

L'authentification API sécurisée repose sur : OAuth 2.0 avec flows appropriés (PKCE pour les clients publics, Client Credentials pour machine-to-machine), JWT RS256/ES256 avec vérification complète (exp, iss, aud, nbf, signature), access tokens à courte durée (15min) + refresh tokens révocables, mTLS pour les communications service-à-service critiques, et Rate Limiting strict sur tous les endpoints d'authentification. Les bibliothèques d'authentification validées (passport.js, Spring Security, Django REST Auth) réduisent le risque d'implémentation incorrecte.

Tests de sécurité pour l'authentification API

Les tests d'authentification API vérifient : utilisation de tokens expirés (doit retourner 401), tokens avec algorithme "none" (doit être rejeté), rejeu de tokens révoqués après logout (doit être rejeté), brute force sur /auth/login (doit être bloqué après N tentatives), accès sans token à des endpoints protégés (doit retourner 401). Ces tests sont automatisables via OWASP ZAP scripts ou des suites de tests de régression de sécurité spécifiques aux APIs.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis