Aller au contenu
BreachVex
guides··6 min read

Liste de contrôle pour la sécurité des API en 2026

Les vulnérabilités des API dominent le classement OWASP pour une bonne raison — les API exposent directement votre modèle de données. Cette liste couvre les dix catégories qui représentent la majorité des résultats exploitables : attaques JWT, IDOR/BOLA, assignation de masse, injection, limitation de débit, CORS et vecteurs spécifiques à GraphQL.

Authentification

alg:none pour JWT reste exploitable dans les bibliothèques non patchées. Appliquez toujours une liste d'algorithmes autorisés côté serveur — ne faites jamais confiance à l'en-tête alg transmis par le client.

  • L'algorithme JWT est soumis à une liste d'autorisation côté serveur (RS256 ou HS256 uniquement — jamais none)
  • La vérification de signature JWT est appliquée sur chaque point d'entrée protégé
  • L'expiration JWT (claim exp) est validée ; les tokens ne sont pas acceptés indéfiniment
  • La rotation du secret JWT est documentée et testée
  • Le flux OAuth2 par code d'autorisation utilise le paramètre state pour prévenir le CSRF
  • Le redirect_uri OAuth2 est validé contre une liste d'autorisation stricte (pas de redirection ouverte)
  • OAuth2 PKCE est appliqué pour les clients publics (SPA, applications mobiles)
  • Les clés API ne sont pas transmises dans les paramètres de requête URL (elles apparaissent dans les journaux)
  • Les tokens Bearer ne sont pas enregistrés dans les journaux d'application ou d'accès
  • Les tokens de réinitialisation de mot de passe sont à usage unique et expirent dans les 15 minutes

Autorisations (IDOR / BOLA)

L'IDOR est le résultat d'API critique le plus fréquent. Si votre point d'entrée accepte un paramètre d'identifiant et renvoie des données, il doit vérifier que l'appelant est bien propriétaire de cette ressource — à chaque requête, à chaque couche.

  • Chaque point d'entrée acceptant un identifiant de ressource valide la propriété vis-à-vis de l'utilisateur authentifié
  • Des identifiants UUID sont utilisés à la place d'entiers séquentiels (réduit l'énumération, mais ne remplace pas les contrôles d'autorisation)
  • Les points d'entrée d'administration sont séparés des points d'entrée utilisateur et filtrés au niveau de l'infrastructure
  • L'élévation de privilèges horizontale est testée : l'Utilisateur A peut-il accéder aux données de l'Utilisateur B avec son propre token valide ?
  • L'élévation de privilèges verticale est testée : un utilisateur standard peut-il atteindre des points d'entrée réservés aux administrateurs ?
  • Les requêtes GraphQL avec des résolveurs imbriqués appliquent les contrôles d'autorisation à chaque niveau de résolveur, pas seulement à la racine

Validation des entrées et injection

  • Tous les paramètres de requête et champs du corps de la requête sont validés contre un schéma explicite (longueur, type, format)
  • Les requêtes SQL utilisent des instructions paramétrées ; l'échappement des requêtes brutes ORM est audité
  • Les vecteurs d'injection NoSQL sont testés pour MongoDB ($where, $regex), ElasticSearch (_search) et Redis EVAL
  • L'injection de commandes est testée sur tout point d'entrée qui exécute des commandes système (exec, spawn, system)
  • L'injection de templates côté serveur (SSTI) est testée sur les points d'entrée qui restituent du contenu fourni par l'utilisateur
  • Les entrées XML sont analysées avec la résolution des entités externes désactivée (FEATURE_SECURE_PROCESSING)
  • Les points d'entrée de téléversement de fichiers valident le type MIME côté serveur (pas uniquement côté client), vérifient les magic bytes, et restreignent les chemins d'exécution

Assignation de masse

L'assignation de masse est fréquemment introduite silencieusement lors de l'ajout de nouveaux champs à un modèle. Une liste d'autorisation des champs acceptés doit être appliquée au niveau de la désérialisation, pas seulement au niveau de la base de données.

  • La désérialisation des requêtes utilise une liste d'autorisation explicite des champs acceptés (role, is_admin, credits ne doivent pas être modifiables par les clients)
  • Les schémas Pydantic / Zod / Joi rejettent par défaut les champs inconnus
  • Les champs privilégiés (role, verified, balance, permissions) ne sont jamais mis à jour depuis un JSON fourni par le client
  • Les points d'entrée de création et de mise à jour d'objets sont testés avec des champs supplémentaires non documentés dans le schéma

Limitation de débit et prévention des abus

  • Les points d'entrée d'authentification (connexion, réinitialisation de mot de passe, vérification MFA) sont soumis à une limitation de débit par IP et par compte
  • Une protection contre le credential stuffing est en place (limitation de débit + CAPTCHA à la connexion après N échecs)
  • Les clés API ont des limites de débit individuelles ; ces limites sont appliquées au niveau de la passerelle, pas de la couche applicative
  • Les points d'entrée en masse (opérations par lot, exports) ont des limites de taille et de débit
  • La profondeur et la complexité des requêtes GraphQL font l'objet de limites

Configuration du CORS

  • Access-Control-Allow-Origin n'est pas défini sur * pour les points d'entrée utilisant des cookies ou des en-têtes d'autorisation
  • La liste d'autorisation CORS est explicite (pas null, pas de wildcard avec les credentials activés)
  • Les réponses preflight n'exposent pas d'en-têtes sensibles aux appelants cross-origin
  • La mauvaise configuration du CORS est testée depuis une origine externe en environnement de staging avant le déploiement en production

Vecteurs spécifiques à GraphQL

  • L'introspection est désactivée en production (ou conditionnée à une authentification)
  • Les attaques par batching sont testées : envoi de plus de 100 requêtes en une seule requête pour contourner les limites de débit
  • Les attaques par alias sont testées : utilisation des alias GraphQL pour répéter des opérations coûteuses
  • La limitation de la profondeur des requêtes est appliquée (maximum par défaut : 7 à 10 niveaux)
  • Les mutations modifiant des données sensibles requièrent une ré-authentification ou une protection CSRF
  • Les points d'entrée de souscription sont authentifiés et limités aux données de l'utilisateur authentifié

Journalisation et surveillance

  • Les erreurs API renvoient des messages génériques aux clients ; les traces de pile et les erreurs SQL ne sont jamais exposées
  • Chaque action authentifiée est journalisée avec l'identifiant utilisateur, l'identifiant de ressource et l'horodatage
  • Les schémas d'accès anormaux (lectures en volume, accès inter-comptes) génèrent des alertes
  • Les événements liés à la sécurité (échecs d'authentification, refus de permissions, exports massifs de données) figurent dans un journal d'audit distinct