Florian Amette

Florian Amette

August 28, 2026

Sécurité des API REST et GraphQL : concevoir un module pratique (OWASP API Security Top 10)

APIRESTGraphQLOWASPsécurité webformation
Sécurité des API REST et GraphQL : concevoir un module pratique (OWASP API Security Top 10)

Sécurité des API REST et GraphQL : concevoir un module pratique (OWASP API Security Top 10)

Pourquoi la sécurité des API est devenue un sujet central en 2026

Les API (Application Programming Interfaces) sont l'infrastructure invisible de l'économie numérique. Chaque application mobile, chaque microservice, chaque plateforme SaaS expose des API — REST ou GraphQL en grande majorité. Pour les attaquants, les API représentent une surface d'attaque considérable : elles exposent directement la logique métier, les données sensibles, et les systèmes d'authentification.

Les chiffres sectoriels sont éloquents : selon les rapports des grandes firmes de sécurité, les attaques ciblant les API représentent aujourd'hui la principale source de violations de données dans le secteur technologique. La directive NIS 2 et le Cyber Resilience Act imposent aux opérateurs d'identifier et de sécuriser leurs surfaces d'exposition, dont les API font partie intégrante.

Pour un étudiant en sécurité web ou en développement sécurisé qui entre sur le marché en 2026, ne pas savoir auditer et sécuriser une API REST ou GraphQL est un angle mort professionnel. Pourtant, de nombreux cursus traitent encore la sécurité web à travers le prisme des applications HTML classiques, avec le OWASP Top 10 comme référentiel, sans intégrer la dimension API qui s'est imposée comme la surface d'attaque dominante.

OWASP API Security Top 10 : le référentiel pédagogique de base

L'OWASP API Security Top 10 (publié en 2023, mis à jour régulièrement) est le référentiel de référence pour enseigner la sécurité des API. Il liste les 10 catégories de vulnérabilités les plus fréquentes et les plus critiques observées dans les API en production.

Tableau de synthèse pédagogique

RangVulnérabilitéDifficulté en labPriorité d'enseignement
API1Broken Object Level Authorization (BOLA)DébutantPrioritaire — très fréquente
API2Broken AuthenticationDébutantPrioritaire — impact élevé
API3Broken Object Property Level AuthorizationIntermédiaireEssentielle
API4Unrestricted Resource ConsumptionDébutantUtile — DoS doux
API5Broken Function Level AuthorizationIntermédiairePrioritaire
API6Unrestricted Access to Sensitive Business FlowsAvancéM1+
API7Server Side Request Forgery (SSRF)IntermédiaireEssentielle
API8Security MisconfigurationDébutantPrioritaire
API9Improper Inventory ManagementAvancéM2 / pratique
API10Unsafe Consumption of APIsAvancéM2 / spécialisation

Pour un premier module, concentrez-vous sur API1, API2, API5 et API8 : ces quatre vulnérabilités couvrent les scénarios d'attaque les plus fréquents et les plus faciles à illustrer en lab.

Les vulnérabilités GraphQL spécifiques

GraphQL introduit des problématiques de sécurité que REST ne connaît pas. Il est important de les enseigner séparément, une fois les bases REST maîtrisées.

Introspection exposée en production

GraphQL dispose nativement d'une fonctionnalité d'introspection qui permet d'interroger l'API pour connaître son schéma complet : tous les types, toutes les requêtes et mutations disponibles. En production, laisser l'introspection active expose la totalité de la surface d'attaque à un attaquant non authentifié.

En cours, l'exercice est simple et frappant : connecter Postman ou Burp Suite à une API GraphQL de démonstration, exécuter la requête d'introspection, et récupérer la liste complète des endpoints et des données exposées. Le résultat illustre en 10 minutes l'impact d'une mauvaise configuration.

Batching attacks et rate limiting

GraphQL permet d'envoyer plusieurs requêtes dans un seul appel HTTP (batching). Sans rate limiting, cela permet à un attaquant d'exécuter des dizaines de requêtes simultanées — utile pour le bruteforce d'identifiants ou l'énumération d'objets — en contournant les mécanismes de limitation habituels.

Nested queries et déni de service

Une requête GraphQL mal conçue peut provoquer une explosion de la complexité côté serveur : une requête imbriquant 10 niveaux de relations dans un schéma circulaire peut générer des milliers de requêtes en base de données. En cours, cet exercice illustre comment un attaquant peut provoquer un déni de service applicatif sans envoyer de trafic réseau inhabituel.

Structure du module : 18 heures en 6 séances

Séance 1 — Introduction et OWASP API Security Top 10 (3h)

Objectifs : comprendre ce qu'est une API, les différences entre REST et GraphQL, et cartographier les vulnérabilités du Top 10.

  • 45 min : qu'est-ce qu'une API REST ? Headers, verbes HTTP, codes de réponse, authentification (Basic, Token, OAuth 2.0, JWT). Différences avec GraphQL.
  • 60 min : OWASP API Security Top 10 — présentation illustrée de chaque catégorie avec des exemples de requêtes vulnérables vs sécurisées
  • 75 min : prise en main de crAPI (Completely Ridiculous API) — exploration libre pour identifier le fonctionnement de l'application et ses endpoints

Séance 2 — BOLA et authentification cassée (3h)

Objectifs : exploiter et corriger les vulnérabilités API1 et API2 sur crAPI.

  • Lab 1 (90 min) : BOLA — l'étudiant découvre qu'en modifiant l'ID d'objet dans une requête, il accède aux données d'autres utilisateurs. Exploitation, documentation de la preuve (requête curl), analyse de la vulnérabilité dans le code source fourni.
  • Lab 2 (60 min) : Broken Authentication — token JWT sans vérification de signature, token sans expiration, endpoints sans authentification requise.
  • Débrief (30 min) : comment corriger chaque vulnérabilité (Authorization header, middleware d'autorisation, JWT avec signature RS256)

Séance 3 — Autorisation et exposition de données (3h)

Objectifs : comprendre API3 (Mass Assignment), API5 (Broken Function Level Authorization), API8 (Security Misconfiguration).

  • Lab : un formulaire d'inscription accepte des champs supplémentaires non documentés et les écrit en base. L'étudiant passe role: admin dans le corps de la requête et obtient des droits administrateur.
  • Lab : une route d'administration (/api/admin/users) n'est pas protégée par un contrôle d'accès au niveau fonction. L'étudiant l'accède sans être administrateur.
  • Lab : l'API expose une stack trace complète en cas d'erreur, révélant la version du framework et les chemins internes.

Séances 4-5 — GraphQL et SSRF (6h)

Objectifs : reproduire les vulnérabilités GraphQL spécifiques ; exploiter une SSRF via une API.

  • Introspection GraphQL : récupérer le schéma, identifier les mutations dangereuses
  • Batching attack : tester un endpoint de vérification de coupon en envoyant 100 codes par lot
  • SSRF : une API qui accepte une URL externe en paramètre (ex. : pour générer une miniature) peut être détournée pour interroger des services internes non exposés (metadata AWS, localhost:8080)

Séance 6 — Projet d'audit et restitution (3h)

Objectifs : conduire un audit complet sur un environnement inconnu, rédiger un rapport.

Le formateur déploie une version de crAPI avec 5 vulnérabilités activées (parmi les 10 du Top 10). Les étudiants ont 2 heures pour les trouver, les exploiter et les documenter. La dernière heure est consacrée à la restitution orale et au débriefing collectif.

Outils recommandés pour les labs

Burp Suite Community : le couteau suisse

Burp Suite Community Edition est l'outil de référence pour l'audit d'API. En cours, il permet d'intercepter les requêtes HTTP, de modifier les paramètres à la volée, de rejouer des requêtes modifiées, et d'automatiser des tests basiques. Son interface graphique rend les concepts d'authentification et d'autorisation très lisibles pour les étudiants.

Postman : la lisibilité pour les débutants

Postman est plus accessible que Burp Suite pour les débutants. Les collections Postman permettent de documenter les requêtes et les résultats, et de partager des suites de tests. En cours, chaque étudiant peut exporter sa collection comme preuve de ses investigations.

crAPI et dvAPI : les labs dédiés

crAPI (github.com/OWASP/crAPI) est l'application pédagogique de référence de l'OWASP pour la sécurité des API. Elle simule une plateforme de gestion de véhicules avec 10 vulnérabilités alignées sur le Top 10. Elle s'installe en Docker avec une commande.

dvAPI (Damn Vulnerable API) est une alternative plus légère, idéale pour les TP courts ciblant 2 à 3 vulnérabilités spécifiques.

Évaluation orientée métier

Rapport de pentest API

L'évaluation la plus formatrice est un rapport de pentest API sur un environnement de lab. Le rapport doit suivre la structure d'un rapport professionnel :

  1. Résumé exécutif (non technique) : 3 à 5 phrases sur les risques principaux
  2. Méthodologie : outils utilisés, périmètre testé, durée
  3. Vulnérabilités : pour chacune — titre, criticité CVSS, description, preuve (requête + réponse), impact, recommandation de correction
  4. Annexes : captures d'écran, requêtes curl ou collections Postman

La rubric d'évaluation porte sur : la complétude (toutes les vulnérabilités trouvées), la justesse technique (CVSS correct, vulnérabilité bien identifiée), la qualité des recommandations, et la lisibilité du rapport.

Pour les développeurs : l'audit de code sécurisé

Pour les filières développement sécurisé, l'évaluation peut prendre la forme d'un audit de code : l'étudiant analyse le code source d'une API vulnérable (Python/Flask, Node.js/Express) et identifie les vulnérabilités directement dans le code avant même de les exploiter. Cette compétence est distincte du pentest et particulièrement valorisée dans les équipes DevSecOps.

Liens avec les métiers et les certifications

La sécurité des API est une compétence transversale qui touche plusieurs profils :

  • Développeur sécurisé : conception et implémentation d'API sécurisées dès la phase de développement
  • Pentesteur web : audit des API dans le périmètre des tests d'intrusion applicatifs
  • Analyste SOC : détection des attaques API à partir des logs d'accès et des anomalies comportementales

Les certifications qui valorisent cette compétence incluent le OSCP (pour la partie exploitation web avancée) et le eWPTv2 (eLearnSecurity Web Application Penetration Tester), qui intègre explicitement la sécurité des API dans son curriculum.

Ce qu'il faut retenir

  • OWASP API Security Top 10 est le référentiel pédagogique de base : commencez par API1 (BOLA), API2 (Broken Authentication) et API8 (Security Misconfiguration), les plus fréquentes et les plus simples à illustrer.
  • crAPI est le lab pédagogique idéal : une application volontairement vulnérable, installable en Docker, directement alignée sur le Top 10.
  • GraphQL introduit des problématiques spécifiques (introspection, batching attacks) qui s'enseignent après les bases REST, pas en parallèle.
  • Burp Suite Community + Postman couvrent 95 % des besoins outillage d'un cours sécurité API de niveau L3 à M1.
  • Le rapport de pentest API est l'évaluation la plus proche du terrain professionnel : il développe simultanément les compétences techniques, la rigueur documentaire et la communication du risque.

Vous souhaitez intégrer un module sécurité des API dans votre cursus ?
Retrouvez des intervenants spécialisés en sécurité web et en test d'intrusion applicatif sur Cyber Teachers, sélectionnés pour leur expertise terrain et leur aptitude à enseigner des compétences directement applicables.

Tous les articles →

Transformez vos formations cybersécurité avec des experts

Expert qualifié en 24h • Formation sur-mesure • Consultation gratuite

Cyber Teachers