La roadmap API security 2026 se structure en 6 niveaux progressifs, centrés sur la spécificité des API REST, GraphQL et gRPC modernes. Le socle HTTP et OAuth 2.0 (niveau 1) amène au niveau junior embauchable en API security (12 à 18 mois depuis un poste dev backend confirmé). La maîtrise complète de l'OWASP API Security Top 10 édition 2023 (niveau 2) constitue le cœur du métier. Les niveaux 3 à 5 couvrent l'authentification OAuth 2.0 avancée et mTLS, l'outillage de test automatisé, la gouvernance API (discovery, gateway, WAF), et le niveau 6 la spécialisation senior (GraphQL security, API zero trust, supply chain). Cet article n'est pas un guide généraliste AppSec — pour cela, voir Roadmap AppSec Engineer. C'est un skill tree API-first spécifique, avec concepts précis, outils réellement utilisés en production France 2026 (Burp, Schemathesis, Kong, 42Crunch), certifications à ROI marché et projets de validation pratique chronométrés par niveau.
1. Niveau 1 — Socle HTTP, REST et protocoles API
Pré-requis indispensable. Sans maîtrise fluide de HTTP moderne et des paradigmes API, les niveaux supérieurs reposent sur du sable.
Concepts à maîtriser
- HTTP/1.1 et HTTP/2 : méthodes (GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD), statuts (2xx, 3xx, 4xx, 5xx), headers (Authorization, Content-Type, Accept, Origin, Referer), cookies (Secure, HttpOnly, SameSite), CORS préflight, cache-control.
- Encodage et sérialisation : JSON RFC 8259, URL encoding, base64, form-data, multipart/form-data, Content-Type negotiation.
- REST architectural constraints : statelessness, resource-oriented URIs, verbes HTTP cohérents, HATEOAS (optionnel mais à connaître), niveaux 0 à 3 du modèle Richardson.
- GraphQL fondamentaux : schema, query, mutation, subscription, resolver, introspection, fragments.
- gRPC basics : Protobuf IDL, unary vs streaming, HTTP/2 transport, avantages vs REST.
- OpenAPI Specification (OAS) 3.1 : paths, operations, parameters, schemas, security schemes, components réutilisables.
- JSON Schema draft 2020-12 : validation de structure, additionalProperties, oneOf/anyOf/allOf, format validators.
Outils
- Postman ou Bruno (open source, alternative moderne) pour l'exploration et la documentation d'API.
- curl en ligne de commande : indispensable pour tests et scripts d'audit.
- httpie : alternative lisible à curl pour JSON.
- jq : manipulation JSON en pipeline.
- Swagger Editor et Redocly pour visualiser et valider une spec OpenAPI.
Projet de validation niveau 1
Concevoir et déployer en 1-2 jours une API REST Node.js ou Python avec 6-8 endpoints (CRUD sur 2 ressources + authentification JWT), documentée en OpenAPI 3.1 complet (schemas de réponse, codes d'erreur, security schemes), testée via Postman ou Bruno collection. Livrable : repo GitHub avec spec OpenAPI, README décrivant les choix, collection Postman exportée. Si vous le faites sans copier-coller, niveau 1 validé.
2. Niveau 2 — OWASP API Security Top 10 édition 2023
Le cœur théorique et pratique du métier API security. L'OWASP API Security Top 10 édition 2023 (sortie publique juin 2023) remplace l'édition 2019. Chaque catégorie doit être exploitée en lab et défendue en code.
| Code | Catégorie 2023 | Résumé | Équivalent 2019 |
|---|---|---|---|
| API1:2023 | Broken Object Level Authorization (BOLA) | Accès non autorisé à un objet par ID manipulé | API1:2019 (identique) |
| API2:2023 | Broken Authentication | Failles auth token, JWT, OAuth, session | API2:2019 |
| API3:2023 | Broken Object Property Level Authorization | Fusion BFLA + Mass Assignment 2019 | API3 + API6:2019 |
| API4:2023 | Unrestricted Resource Consumption | DoS par ressources excessives, pagination non bornée | API4:2019 |
| API5:2023 | Broken Function Level Authorization (BFLA) | Accès fonction admin sans privilège | API5:2019 |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | Abus de fonctions métier légitimes (scalping, fraud) | Nouveau 2023 |
| API7:2023 | Server Side Request Forgery (SSRF) | API backend envoie requête vers URL contrôlée attaquant | Nouveau 2023 |
| API8:2023 | Security Misconfiguration | Headers, TLS, CORS, endpoints dev exposés | API7:2019 |
| API9:2023 | Improper Inventory Management | Shadow API, zombie API, versions dépréciées exposées | API9:2019 |
| API10:2023 | Unsafe Consumption of APIs | Confiance aveugle en API tierces consommées | Nouveau 2023 |
Les trois changements majeurs vs 2019
- Fusion BFLA et Mass Assignment en API3:2023 — reconnaissance que la distinction n'était pas opérante en production.
- Nouvelle API6 Unrestricted Access to Sensitive Business Flows — couvre les abus type fraud, inventory hoarding, mass account creation.
- Nouvelle API7 SSRF et API10 Unsafe Consumption — reconnaissance des architectures API-to-API où le backend consomme lui-même des API externes.
Labs obligatoires pour valider le niveau 2
- crAPI (Completely Ridiculous API, projet OWASP, cloné via Docker Compose) : pratique intégrée des 10 catégories dans un contexte applicatif réaliste (marketplace véhicules).
- VAmPI (Vulnerable API) : focus authentification JWT et IDOR.
- PortSwigger Web Security Academy, section API : 20+ labs gratuits avec focus sur BOLA, mass assignment, GraphQL.
- DVGA (Damn Vulnerable GraphQL Application) : spécifique GraphQL.
Certifications
- Burp Suite Certified Practitioner (environ 99 $) : certification exhaustive web et API, pratique hands-on, bon ROI.
- CompTIA Security+ SY0-701 (environ 400 €) : ticket d'entrée marché, transverse.
Projet de validation niveau 2
Documenter un write-up complet de 40-80 pages Markdown couvrant les 10 catégories API Top 10 2023, chacune avec : 1) exemple de code vulnérable (Node ou Python), 2) scénario d'exploitation step-by-step avec captures Burp, 3) correction en code sécurisé avec explication, 4) mapping CWE et CVSS v3.1 indicatif, 5) test automatisé qui détecte la régression. Publier sur GitHub ou blog personnel.
3. Niveau 3 — Authentification et autorisation API avancées
L'authentification est la surface d'attaque numéro un des API modernes. Un niveau API security junior doit maîtriser au minimum OAuth 2.0 complet, JWT bien utilisé, et la cartographie des erreurs classiques.
Concepts à maîtriser
- OAuth 2.0 (RFC 6749) et RFC 9700 Best Current Practice (BCP) publié décembre 2024 : flows authorization code + PKCE obligatoire, client credentials pour machine-to-machine, refresh tokens, audience et scope.
- OpenID Connect (OIDC) 1.0 : id_token vs access_token, userinfo endpoint, discovery, JWKS.
- PKCE (Proof Key for Code Exchange, RFC 7636) : obligatoire pour clients publics et fortement recommandé partout en 2026.
- JWT RFC 7519 et RFC 8725 BCP : signature (HS256 vs RS256 vs EdDSA), validation exp, nbf, iss, aud, jti ; pièges classiques (algorithm confusion, key confusion, none algorithm, kid injection).
- mTLS (mutual TLS) : authentification par certificat client, pratique en B2B et dans les API internes, intégration SPIFFE/SPIRE en cloud native.
- API keys : usage légitime pour M2M rate-limiting et identification, pas pour authentification de confiance sans complément.
- HMAC request signing : pattern AWS Sig v4, rarement requis hors intégration avec certains clouds ou paiements.
- Autorisation fine : RBAC, ABAC (attribute-based), ReBAC (relationship-based, popularisé par Zanzibar Google), policy engines (OPA, Cedar AWS, OpenFGA, SpiceDB).
Attaques et contre-mesures classiques
- Algorithm confusion JWT : forcer HS256 sur une clé publique RS256 envoyée comme secret HMAC → toujours whitelister l'algorithme attendu.
- kid injection : manipuler le header kid pour forcer un chargement de clé malveillant → validation stricte du kid dans un keyset connu.
- OAuth redirect_uri bypass : partial match, open redirect, fragment smuggling → matching strict exact URI.
- Token en URL : fuite via logs, Referer → toujours dans Authorization header, jamais en query string.
- Refresh token rotation absente : compromission durable → rotation obligatoire (refresh token rotation RFC draft de la BCP 2024).
- JWT au-delà de la signature : oubli de iss, aud, exp → validation exhaustive systématique.
Outils et labs
- jwt.io et jwt_tool (ticarpi, Python) pour auditer et forger des JWT.
- Authlib (Python), node-oauth2-server (Node), Spring Authorization Server (Java) pour comprendre l'implémentation côté Authorization Server.
- Keycloak open source, Ory Hydra, Auth0 free tier, AWS Cognito pour expérimenter des IdP en conditions réelles.
- PortSwigger Web Security Academy, OAuth 2.0 vulnerabilities : labs dédiés.
Projet de validation niveau 3
Construire en 2-3 jours un setup complet Keycloak local en Docker, y intégrer une API backend Go ou Python qui valide les tokens OIDC (iss, aud, exp, nonce, signature), implémenter le flow authorization code + PKCE côté front-end minimal, rotation refresh token, logout OIDC end-session. Puis écrire un mini pentest suite en Python avec requests qui teste 8 attaques classiques (algorithm confusion, kid injection, expired token, wrong audience, wrong issuer, manipulated claims, replay sans jti, JWT injection via kid). Documenter les résultats.
4. Niveau 4 — Tests et outils API security
Transformer la connaissance théorique en capacité de test systématique, manuel et automatisé.
Concepts à maîtriser
- Testing manuel Burp Suite : Repeater, Intruder, Sequencer, Decoder, Turbo Intruder (extension) pour brute-force et race conditions, Collaborator pour OOB (out-of-band) et SSRF.
- Testing automatisé spec-driven : property-based testing depuis OpenAPI avec Schemathesis, stateful fuzzing avec RESTler ou ZAP API scan.
- Contract testing sécurité : validation qu'une API respecte sa spec OpenAPI en production via Dredd, Optic ou Pact.
- GraphQL testing : InQL extension Burp, GraphQL Voyager pour explorer schéma, graphql-path-enum pour introspection et path discovery.
- Rate limiting et abuse testing : vérifier le comportement sous 429, bypass via IP rotation, bypass via headers (X-Forwarded-For, X-Real-IP).
- Authorization matrix testing : tester chaque combinaison utilisateur/ressource/action, automatisé avec Autorize (extension Burp).
Outils utilisés en production France 2026
| Catégorie | Open source | Premium | Usage France |
|---|---|---|---|
| Intercept et manual | Burp Community, ZAP | Burp Professional (475 $/an) | Très forte |
| Spec-driven fuzz | Schemathesis, RESTler | StackHawk, 42Crunch | Forte |
| DAST API | ZAP API Scan, Nuclei | Burp Enterprise, Invicti | Forte |
| Contract testing | Dredd, Optic | Pact Broker | Moyenne |
| GraphQL audit | InQL, graphql-cop | Escape GraphQL | Moyenne en croissance |
| Authorization matrix | Autorize, AuthMatrix | ShieldAPI | Moyenne |
| Specification linting | Spectral, vacuum | 42Crunch Audit | Forte |
Outils de reporting
- SARIF (Static Analysis Results Interchange Format) pour l'ingestion dans GitHub Advanced Security et GitLab Ultimate.
- DefectDojo (OWASP) pour l'agrégation multi-scanners et le tracking longitudinal.
Certifications
- Burp Suite Certified Practitioner (environ 99 $) : très valorisé à ce niveau.
- OSWE (Offensive Security Web Expert, environ 1 749 $) : pointe whitebox audit web et API, très différenciant.
- SANS SEC552 Bug Bounty and API Hacking : cher (environ 8-9 k€) mais référence cursus pour ceux qui ont le financement.
Projet de validation niveau 4
Construire un pipeline GitHub Actions qui, pour un repo d'API, exécute : 1) lint OpenAPI via Spectral avec rules customs sécurité, 2) fuzz spec-driven via Schemathesis sur 10+ endpoints, 3) ZAP API Scan en baseline contre un environnement de preview, 4) gitleaks sur le code, 5) Semgrep avec rules API security (sauveture: p/owasp-top-ten, p/jwt, custom rules BOLA detection). Tous les résultats ingestés en SARIF vers GitHub Security tab. Dashboard DefectDojo bonus.
# Extrait pipeline GitHub Actions API security niveau 4
name: api-security-pipeline
on: [push, pull_request]
jobs:
openapi-lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Spectral lint OpenAPI
run: |
npm install -g @stoplight/spectral-cli
spectral lint openapi.yaml --ruleset .spectral.yaml -f sarif -o spectral.sarif
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: spectral.sarif
schemathesis-fuzz:
runs-on: ubuntu-latest
services:
api:
image: myapi:test
ports: ["8080:8080"]
steps:
- uses: actions/checkout@v4
- name: Run Schemathesis
run: |
pip install schemathesis
schemathesis run http://localhost:8080/openapi.json \
--checks all \
--hypothesis-max-examples 100 \
--workers 4 \
--report schemathesis.tar.gz
zap-api-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: ZAP API Scan
uses: zaproxy/action-api-scan@v0.7.0
with:
target: "http://localhost:8080/openapi.json"
format: openapi
cmd_options: "-a -j"
semgrep-api-rules:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: returntocorp/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/jwt
.semgrep/api-security-rules.yaml
generateSarif: "1"5. Niveau 5 — API governance, discovery et gateway security
Le niveau qui fait la différence entre un pentester API et un ingénieur API security. Capacité à sécuriser un parc d'API à l'échelle d'une organisation, pas endpoint par endpoint.
5.1 API inventory et discovery
Pain point numéro un des grands comptes en 2026 : personne ne sait exactement combien d'API l'organisation expose. Les études récentes (Salt Labs Q3 2024, Noname 2024 Security Report) estiment qu'entre 20 et 35 pourcent des API exposées par une entreprise moyenne sont des shadow API (non documentées) ou des zombie API (versions dépréciées encore accessibles).
Concepts à maîtriser
- Shadow API : API exposées en production sans passer par la gouvernance centrale.
- Zombie API : anciennes versions v1 ou v2 encore accessibles après migration v3.
- API sprawl : multiplication non contrôlée d'API similaires ou redondantes.
- Discovery passif : analyse des logs de gateway, flux de trafic, DNS, certificats TLS.
- Discovery actif : scan horizontal, fuzzing de versions, analyse de JavaScript client pour trouver les endpoints appelés.
Outils premium leaders 2026
- Salt Security, Noname Security, Traceable AI, Akamai API Security (acquis Neosec 2023), Cequence.
- 42Crunch (plateforme spec-centric française, approche complémentaire).
Outils open source
- kiterunner (Assetnote) pour fuzzing de routes API via wordlists content-type-aware.
- ffuf + wordlists API (SecLists).
- APIsec University et labs associés pour pratiquer la discovery.
5.2 API gateway et WAF security
L'API gateway est le point de contrôle central. Mal configuré, il devient la faille unique qui expose tout.
Concepts à maîtriser
- Rate limiting stratégies : fixed window, sliding window, token bucket, distinction par IP vs API key vs user.
- Schema enforcement : validation stricte de la spec OpenAPI en entrée et sortie, rejet des propriétés additionnelles non déclarées.
- Authentication offload : vérification JWT et OAuth au gateway avant transmission au backend, avec pass-through de claims validés.
- Request and response transformation : sanitization, masking PII, stripping headers sensibles.
- mTLS termination et re-origination : architecture typique gateway public HTTPS + mTLS vers backends internes.
- WAF et ML-based anomaly detection : AWS WAF + API Shield, Cloudflare API Shield, Akamai API Security.
Outils en production 2026
| Catégorie | Leaders open source | Leaders managed |
|---|---|---|
| API gateway | Kong OSS, Traefik, KrakenD, Tyk OSS | Apigee, AWS API Gateway, Azure APIM, Kong Enterprise |
| WAF | ModSecurity, Coraza (WASM) | Cloudflare, AWS WAF, Akamai, F5 |
| Service mesh | Istio, Linkerd, Consul | Tetrate TSB, Solo.io Gloo Mesh |
5.3 API logging, monitoring et detection
Concepts à maîtriser
- Audit logging structuré : format JSON, champs obligatoires (user_id, api_route, http_method, response_status, latency, trace_id, tenant_id).
- Sensitive data in logs : masquer PII, tokens, mots de passe ; règles de redaction automatisée.
- Anomaly detection : patterns de consommation anormaux (pics volume, géo inhabituelle, user-agent rare).
- Mapping MITRE ATT&CK for Cloud and APIs : techniques T1040 sniffing, T1078 valid accounts, T1552 unsecured credentials.
Projet de validation niveau 5
Déployer un parc d'API fictif (3-5 services) derrière un Kong ou AWS API Gateway, avec : 1) spec OpenAPI enforcement au gateway, 2) rate limiting différencié par tier, 3) JWT validation au gateway avant pass-through backend, 4) logging structuré vers un Loki ou CloudWatch Logs, 5) un dashboard Grafana qui remonte les anomalies (spike 429, 401, géo). Documentation 30-50 pages incluant architecture decisions records et threat model STRIDE du setup.
6. Niveau 6 — Spécialisation API security senior
Après 4 à 7 ans d'expérience API security cumulée, trois spécialisations s'ouvrent pour atteindre le plafond salarial et les rôles principal, staff engineer ou freelance haut de gamme.
6.1 GraphQL security deep expertise
Concepts avancés
- Query complexity analysis : calcul de coût de requête, rejection au-delà d'un seuil (graphql-cost-analysis, graphql-query-complexity).
- Batching attacks : exploitation d'aliases et queries batchées pour brute-force à coût faible.
- Introspection en production : pivot attaque si non désactivée.
- Federation et schema stitching : risques spécifiques Apollo Federation, SSRF inter-services.
- Persisted queries et whitelisting comme défense profonde.
6.2 Zero Trust API et SPIFFE/SPIRE
Concepts avancés
- Zero Trust Network Access (ZTNA) appliqué aux API : pas de confiance réseau implicite, vérification continue.
- SPIFFE (Secure Production Identity Framework For Everyone) et SPIRE (CNCF incubating) pour identités workload universelles.
- Workload identity : EKS IRSA, GKE Workload Identity, Azure AD Workload Identity, SPIFFE federation.
- Service mesh mTLS automatique : Istio, Linkerd, Consul Connect.
6.3 API supply chain security
Concepts avancés
- SBOM pour clients API consommés : tracking des dépendances SDK, vulnérabilités transitives.
- Dependency confusion dans les SDK API : pattern d'attaque type CVE-2021-43176.
- API signing et verification : HTTP Message Signatures (RFC 9421, février 2024), signed OpenAPI specs.
- Supply chain levels appliqués aux API : SLSA provenance pour le déploiement, attestations in-toto.
Signaux de maîtrise niveau 6
- CVE publiées sur vulnérabilités API (OWASP API Top 10 ou spécifiques framework).
- Contribution open source majeure (Schemathesis, RESTler, 42Crunch tools, OWASP crAPI, Kong plugins).
- Confs techniques API-centric (API Days Paris, apidays.global, PlatformCon, KubeCon workshops).
- Publications techniques (blog, whitepapers, présentations OWASP Chapter Paris).
Projet typique niveau 6
Développer et maintenir un outil open source API security utile à la communauté. Exemples récents réussis : un scanner GraphQL automatisé, un linter OpenAPI sécurité, un plugin Kong de detection automatique, un framework de testing API spec-driven. Viser 500+ stars GitHub et 10+ contributeurs externes pour valider la reconnaissance.
7. Cartographie outils par niveau (synthèse 2026)
Résumé par niveau des outils réellement utilisés en France en 2026, hors marketing.
| Niveau | Outils principaux à maîtriser |
|---|---|
| 1 | Postman ou Bruno, curl, httpie, jq, Swagger Editor, Redocly |
| 2 | Burp Community, crAPI, VAmPI, DVGA, PortSwigger Academy API labs |
| 3 | jwt_tool, jwt.io, Keycloak, Ory Hydra, PortSwigger OAuth labs |
| 4 | Burp Pro, Schemathesis, RESTler, ZAP API Scan, Spectral, InQL |
| 5 | Kong, AWS API Gateway, Salt ou Noname ou 42Crunch, Loki, Grafana |
| 6 | Istio ou Linkerd, SPIRE, HTTP Message Signatures, contrib open source |
Règle stratégique : la stack open source (Burp Community, Schemathesis, ZAP, Kong OSS, Keycloak) couvre 80 pourcent des compétences nécessaires jusqu'au niveau 5. Les outils premium (Burp Pro, Salt, Noname, 42Crunch) accélèrent mais ne remplacent pas la compréhension conceptuelle.
Points clés à retenir
- 6 niveaux progressifs : socle HTTP-REST-GraphQL, OWASP API Top 10 2023, auth OAuth 2.0 et mTLS, tests automatisés, governance et discovery, spécialisation expert.
- Junior API security embauchable = niveaux 1 à 3 + 40-60 % du niveau 4, atteint en 12-18 mois depuis un poste dev backend.
- OWASP API Security Top 10 édition 2023 : référentiel obligatoire, 3 nouvelles catégories vs 2019 (API6 business flows, API7 SSRF, API10 consumption).
- Stack open source d'abord : Burp Community, Schemathesis, ZAP, Spectral, Keycloak, Kong OSS, InQL.
- Certifications à ROI marché : Burp Suite Certified Practitioner (niveau 4), OSWE (niveau 5), CSSLP pour architecture.
- Labs obligatoires : crAPI, VAmPI, DVGA, PortSwigger API labs — viser 60+ heures de pratique avant candidature junior.
- Spécialisation niveau 6 : GraphQL deep, Zero Trust API avec SPIFFE, API supply chain — optionnelles mais décisives pour plafond salarial.
Pour aller plus loin
- Roadmap AppSec Engineer — parcours AppSec généraliste complémentaire.
- Introduction OWASP Top 10 — base OWASP Top 10 Web classique.
- Salaire AppSec engineer — grilles AppSec incluant profil API security.
- Roadmap DevSecOps — skill tree DevSecOps qui intègre l'API security dans le pipeline.
- SAST vs DAST — comparaison des paradigmes de scan applicables aux API.






