Elise Bernard
Ingenieure securite applicative
Comment auditer la securite de vos API REST en 7 etapes
TL;DR
- ▸ Les API REST representent 83% de la surface d'attaque des applications modernes selon le rapport State of API Security 2025
- ▸ Un audit systematique en 7 etapes couvre authentification, autorisation, validation, rate limiting, logging, configuration et tests continus
- ▸ Chaque etape inclut des commandes et outils concrets (curl, OWASP ZAP, Burp Suite, nuclei) directement applicables
- ▸ Applicable aux API internes et externes, conforme OWASP API Security Top 10 2023
Les API REST sont devenues le systeme nerveux des architectures modernes. Chaque application SaaS, chaque microservice, chaque integration tierce repose sur des endpoints qui echangent des donnees sensibles en permanence. Pourtant, la securite de ces interfaces reste souvent un angle mort : les equipes de developpement se concentrent sur la fonctionnalite, les equipes securite sur le perimetre reseau, et les API restent entre les deux sans responsable clairement designe.
En 2025, Salt Security rapportait que 83% des organisations avaient subi un incident de securite lie a leurs API au cours des 12 derniers mois. Gartner prevoyait des 2022 que les API deviendraient le vecteur d'attaque numero un d'ici 2025 — cette prediction s'est confirmee avec une augmentation de 400% des attaques API entre 2022 et 2025.
Ce guide vous propose une methodologie structuree en 7 etapes pour auditer la securite de vos API REST. Chaque etape est accompagnee de commandes concretes, d'outils recommandes et de criteres de validation. Cette approche est alignee sur le referentiel OWASP API Security Top 10 2023 et enrichie par notre experience de plus de 200 audits API en entreprise.
— Etape 1 : Cartographier l'ensemble de vos endpoints API
Avant de tester quoi que ce soit, vous devez savoir exactement ce que vous protegez. La cartographie des endpoints est l'etape la plus souvent negligee, et pourtant la plus critique. Les shadow APIs — ces endpoints deployes en production sans documentation ni supervision — representent en moyenne 30% de la surface d'attaque reelle d'une organisation.
Commencez par identifier tous les fichiers de specification disponibles. La plupart des frameworks modernes exposent automatiquement une documentation OpenAPI/Swagger :
# Decouverte des specifications OpenAPI
curl -s https://api.example.com/swagger.json | jq '.paths | keys[]'
curl -s https://api.example.com/openapi.yaml
curl -s https://api.example.com/.well-known/openapi.json
curl -s https://api.example.com/v2/api-docs
# Recherche de documentation non referencee
curl -s https://api.example.com/docs
curl -s https://api.example.com/redoc
curl -s https://api.example.com/graphql # GraphQL introspection
Completez cette decouverte passive par un crawling actif avec OWASP ZAP en mode spider API ou Burp Suite Professional avec son crawler REST. L'outil Kiterunner de Assetnote est particulierement efficace pour decouvrir des endpoints caches en testant des wordlists specifiques aux frameworks (Spring Boot, Express, Django, FastAPI) :
# Kiterunner - decouverte d'endpoints caches
kr scan https://api.example.com -w routes-large.kite -x 20
# OWASP ZAP en mode API scan
zap-cli quick-scan -s xss,sqli -r https://api.example.com \
--api-spec openapi.yaml
Documentez chaque endpoint decouvert dans un inventaire structure : methode HTTP, chemin, parametres attendus, authentification requise ou non, et version. Les endpoints sans authentification accessible depuis Internet sont vos priorites immédiates.
— Etape 2 : Auditer l'authentification et la gestion des tokens
L'authentification est votre premiere ligne de defense. Un mecanisme JWT mal implemente peut rendre l'ensemble de votre API vulnerable en quelques secondes. Les erreurs les plus frequentes que nous rencontrons : absence de verification de signature, algorithme none accepte, secrets faibles facilement brute-forces, et tokens sans expiration.
# Decoder un JWT sans verification (analyse)
echo "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature" | \
cut -d'.' -f2 | base64 -d 2>/dev/null | jq .
# Test de l'algorithme "none" (CVE classique)
python3 jwt_tool.py $TOKEN -X a # alg:none attack
python3 jwt_tool.py $TOKEN -X k -pk public.pem # key confusion
# Test avec un token expire
curl -s -o /dev/null -w "%{http_code}" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MDAwMDAwMDB9.sig" \
https://api.example.com/api/me
# Brute-force du secret JWT (hashcat)
hashcat -a 0 -m 16500 jwt.txt wordlist.txt
Verifiez egalement les flux OAuth2 : le redirect_uri est-il strictement valide ? Les tokens de rafraichissement sont-ils revocables ? Les API keys sont-elles transmises en header plutot qu'en parametre d'URL (ou elles apparaissent dans les logs serveur et l'historique navigateur) ?
Points de controle essentiels :
- 1 L'algorithme de signature est-il impose cote serveur (pas cote client) ?
- 2 Les tokens ont-ils une duree de vie raisonnable (15-30 min pour access, 7j pour refresh) ?
- 3 La rotation des secrets est-elle en place et documentee ?
- 4 Les tokens revoques sont-ils effectivement rejetes (blacklist ou verification en temps reel) ?
— Etape 3 : Tester les controles d'autorisation (BOLA/IDOR)
OWASP API1:2023 — Broken Object Level Authorization reste la vulnerabilite API numero un depuis la premiere edition du referentiel. Le principe est simple : un utilisateur authentifie accede aux donnees d'un autre utilisateur en modifiant simplement un identifiant dans la requete. Simple a comprendre, catastrophique en impact, et etonnamment frequent en production.
# Test BOLA - acces horizontal (meme role, autre utilisateur)
curl -H "Authorization: Bearer $USER_A_TOKEN" \
https://api.example.com/api/users/user_B_id/documents
# Test BOLA - enumeration sequentielle
for id in $(seq 1 100); do
status=$(curl -s -o /dev/null -w "%{http_code}" \
-H "Authorization: Bearer $TOKEN" \
"https://api.example.com/api/orders/$id")
[ "$status" = "200" ] && echo "ACCESSIBLE: order $id"
done
# Test d'escalade verticale (role utilisateur -> admin)
curl -H "Authorization: Bearer $USER_TOKEN" \
https://api.example.com/api/admin/users
curl -X DELETE -H "Authorization: Bearer $USER_TOKEN" \
https://api.example.com/api/admin/users/42
Testez systematiquement chaque endpoint avec des identifiants appartenant a d'autres utilisateurs. Les identifiants previsibles (numeriques sequentiels, UUID v1 basees sur le temps) facilitent l'exploitation. Verifiez aussi les endpoints de modification et de suppression — un attaquant qui ne peut pas lire les donnees d'autrui peut parfois les modifier ou les supprimer.
"80% des API que nous auditons en entreprise ont au moins un endpoint sans controle d'autorisation adequat. Le probleme n'est pas technique — c'est un probleme de processus : les developpeurs testent le happy path, pas les cas d'abus."
— Elise Bernard, Ingenieure securite applicative
— Etape 4 : Valider le traitement des entrees et la serialisation
Les API REST acceptent des donnees structurees (JSON, XML) qui sont deserialisees puis traitees par le backend. Chaque parametre est un vecteur d'injection potentiel. Au-dela des classiques SQLi et XSS, les API modernes sont exposees a des risques specifiques : mass assignment (modification de champs non prevus), excessive data exposure (retour de donnees sensibles non filtrees) et injection NoSQL.
# Injection SQL via parametre JSON
curl -X POST https://api.example.com/api/search \
-H "Content-Type: application/json" \
-d '{"query": "test\" OR 1=1 --", "limit": 10}'
# Mass assignment - ajout du role admin
curl -X PUT https://api.example.com/api/users/me \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "John", "role": "admin", "isVerified": true}'
# Test Content-Type enforcement
curl -X POST https://api.example.com/api/data \
-H "Content-Type: text/xml" \
-d '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><root>&xxe;</root>'
# Injection NoSQL (MongoDB)
curl -X POST https://api.example.com/api/login \
-H "Content-Type: application/json" \
-d '{"email": {"$ne": ""}, "password": {"$ne": ""}}'
Verifiez que l'API applique un schema de validation strict (JSON Schema, validation de type, longueur maximale) et qu'elle rejette les champs non attendus. L'endpoint doit retourner exactement les champs necessaires au client — jamais d'objets entiers de base de donnees avec des champs internes (password hash, tokens internes, metadata systeme).
— Etape 5 : Evaluer le rate limiting et la protection anti-abus
Sans rate limiting, votre API est ouverte au brute force, au credential stuffing, au scraping massif et aux attaques par deni de service applicatif. Un attaquant peut tenter des milliers de combinaisons mot de passe, enumerer tous vos utilisateurs ou epuiser vos ressources serveur.
# Test de rate limiting - 100 requetes rapides
for i in $(seq 1 100); do
response=$(curl -s -o /dev/null -w "%{http_code}|%{header}" \
-H "Authorization: Bearer $TOKEN" \
"https://api.example.com/api/users")
echo "Request $i: $response"
done | grep -c "429"
# Verifier les headers de rate limit
curl -s -D - https://api.example.com/api/users \
-H "Authorization: Bearer $TOKEN" | \
grep -i "x-ratelimit\|retry-after"
# Test brute force sur endpoint d'authentification
for i in $(seq 1 50); do
curl -s -o /dev/null -w "Attempt $i: %{http_code}\n" \
-X POST https://api.example.com/api/auth/login \
-H "Content-Type: application/json" \
-d "{\"email\":\"admin@example.com\",\"password\":\"wrong$i\"}"
done
Attendez-vous a recevoir un code HTTP 429 (Too Many Requests) avec les headers X-RateLimit-Limit, X-RateLimit-Remaining et Retry-After. Les endpoints d'authentification doivent avoir des limites plus strictes (5-10 tentatives par minute) que les endpoints de lecture (100-1000 par minute selon l'usage).
— Etape 6 : Verifier la configuration securisee et les headers
La configuration de securite est souvent correcte en developpement puis degradee en production pour "faire marcher les choses". Les erreurs de configuration CORS sont particulierement dangereuses car elles peuvent permettre a n'importe quel site malveillant d'effectuer des requetes authentifiees au nom de vos utilisateurs.
# Test CORS - origine malveillante
curl -s -D - -H "Origin: https://evil-attacker.com" \
https://api.example.com/api/users | \
grep -i "access-control"
# Si "Access-Control-Allow-Origin: https://evil-attacker.com" -> CRITIQUE
# Verification des headers de securite
curl -s -D - https://api.example.com/api/health | grep -iE \
"strict-transport|x-content-type|x-frame|content-security"
# Test TLS - versions et ciphers
nmap --script ssl-enum-ciphers -p 443 api.example.com
testssl.sh --protocols --ciphers https://api.example.com
# Verifier que les erreurs ne leakent pas d'info
curl -s https://api.example.com/api/nonexistent | jq .
# Mauvais: {"error": "TypeError at /app/src/routes/api.js:42", "stack": "..."}
# Bon: {"error": "Not Found", "status": 404}
Verifiez que TLS 1.2 est le minimum supporte (TLS 1.0 et 1.1 sont deprecies), que HSTS est active avec une duree suffisante (min 1 an), et que les messages d'erreur en production ne revelent aucune information technique (pas de stack traces, pas de noms de fichiers, pas de versions de frameworks).
— Etape 7 : Mettre en place le monitoring et l'audit continu
Un audit ponctuel ne suffit pas. Les API evoluent a chaque sprint, et une nouvelle route deployee lundi peut introduire une vulnerabilite BOLA qui ne sera detectee que lors du prochain audit trimestriel — si l'attaquant ne la trouve pas avant. L'audit continu est le seul moyen de maintenir un niveau de securite coherent dans un environnement agile.
# Template Nuclei pour audit API automatise
nuclei -u https://api.example.com -t api/ -severity critical,high \
-header "Authorization: Bearer $TOKEN" \
-o results-$(date +%Y%m%d).json -json
# Integration CI/CD (GitHub Actions example)
- name: API Security Scan
run: |
nuclei -u ${{ secrets.API_URL }} \
-t api/ -severity critical,high \
-header "Authorization: Bearer ${{ secrets.TEST_TOKEN }}" \
-silent -nc
if [ $? -ne 0 ]; then exit 1; fi
# OWASP ZAP en mode CI
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
-t https://api.example.com/openapi.yaml \
-f openapi -r report.html
Configurez votre SIEM pour alerter sur les patterns suspects : rafales de 401/403 depuis une meme IP, pics de requetes sur des endpoints sensibles, acces depuis des geolocalisations inhabituelles. Chaque modification d'endpoint doit declencher un scan automatise avant le merge en production.
"L'automatisation de l'audit API dans la CI/CD est le seul moyen de maintenir la securite a l'echelle. Un audit ponctuel est obsolete en 2 sprints."
— Elise Bernard, Ingenieure securite applicative
— Reference : OWASP API Security Top 10 et etapes d'audit
| Rang | Risque | Etape d'audit | Outils recommandes |
|---|---|---|---|
| API1 | Broken Object Level Authorization | Etape 3 | Burp Autorize, curl, Postman |
| API2 | Broken Authentication | Etape 2 | jwt_tool, hashcat, Burp Intruder |
| API3 | Broken Object Property Level Auth | Etapes 3 + 4 | Burp Repeater, curl, OWASP ZAP |
| API4 | Unrestricted Resource Consumption | Etape 5 | Gatling, k6, scripts bash |
| API5 | Broken Function Level Authorization | Etape 3 | Burp Autorize, curl, Postman |
| API6 | Unrestricted Access to Sensitive Flows | Etape 5 | Burp Intruder, scripts custom |
| API7 | Server Side Request Forgery | Etape 4 | Burp Collaborator, SSRFmap |
| API8 | Security Misconfiguration | Etape 6 | testssl.sh, securityheaders.com, nmap |
| API9 | Improper Inventory Management | Etape 1 | Kiterunner, OWASP ZAP, Burp |
| API10 | Unsafe Consumption of APIs | Etapes 4 + 7 | mitmproxy, Burp, analyse code |
— Conclusion : de l'audit ponctuel a la securite continue
Auditer la securite de vos API REST n'est pas un exercice theorique — c'est une necessitude operationnelle. Les 7 etapes presentees dans ce guide couvrent l'ensemble des vecteurs d'attaque references par l'OWASP et vous permettent d'identifier les vulnerabilites les plus critiques avant qu'un attaquant ne les exploite.
L'erreur la plus courante est de considerer l'audit comme un evenement ponctuel. Dans un environnement ou les API evoluent a chaque sprint, ou chaque nouvelle feature peut introduire une regression de securite, seule une approche d'audit continu — automatisee dans la CI/CD et completee par des revues manuelles trimestrielles — garantit un niveau de protection adequat.
Commencez par l'etape 1 (cartographie) si vous n'avez jamais audite vos API, ou par l'etape 7 (monitoring) si vous avez deja realise un audit initial et souhaitez perenniser les resultats. Dans tous les cas, la priorite absolue reste les controles d'autorisation (etape 3) : c'est la ou nous trouvons le plus de vulnerabilites critiques, et c'est la ou l'impact business est le plus severe.
Besoin d'un audit de securite de vos API ?
Notre equipe d'ingenieurs securite applicative realise des audits complets de vos API REST : authentification, autorisation, injection, configuration. Rapport detaille sous 5 jours ouvrables.
— Questions frequentes
Un audit API se concentre specifiquement sur les interfaces programmatiques : authentification par tokens, autorisation au niveau objet (BOLA), serialisation des donnees et rate limiting. Un pentest classique couvre l'ensemble de l'application web incluant le front-end, les sessions navigateur et les vulnerabilites DOM. L'audit API requiert des outils specialises comme Burp Suite avec des extensions API ou Postman pour tester systematiquement chaque endpoint. Les deux sont complementaires et nous recommandons de les combiner pour une couverture optimale.
Pour une API de taille moyenne (50-100 endpoints), comptez 3 a 5 jours ouvrables pour un audit complet couvrant les 7 etapes. Une API complexe avec microservices peut necessiter 2 a 3 semaines. Un audit automatise initial peut etre realise en quelques heures mais ne remplace pas l'analyse manuelle des controles d'autorisation qui requiert une comprehension du modele metier.
Nos recommandations : OWASP ZAP pour le scanning automatise, Nuclei de ProjectDiscovery pour les templates de detection, jwt_tool pour l'analyse des tokens JWT, Postman ou Insomnia pour les tests manuels, et Kiterunner pour la decouverte d'endpoints. Pour l'analyse de trafic, mitmproxy est excellent en complement de Burp Suite Community Edition. En CI/CD, Newman (Postman CLI) et OWASP ZAP en mode headless sont nos choix par defaut.
Integrez des scans automatises a chaque pull request avec OWASP ZAP en mode API scan ou Nuclei avec des templates personnalises. Configurez des quality gates qui bloquent le deploiement si des vulnerabilites critiques sont detectees. Utilisez des collections Postman/Newman pour valider les controles de securite en continu. Completez par un audit manuel trimestriel pour les tests d'autorisation complexes qui necessitent une comprehension du contexte metier.
RESUMER CET ARTICLE AVEC