Tests de sécurité API : OWASP Top 10, outils et liste de contrôle

Introduction

Les APIs sont le vecteur d'attaque le plus courant dans les applications modernes. Selon Gartner, les attaques d'API sont devenues le vecteur d'attaque le plus fréquent pour les applications web d'entreprise d'ici 2024. Chaque API que vous exposez est un point d'entrée potentiel pour les attaquants, et les tests de sécurité des applications web traditionnels ne suffisent pas à les protéger.

Les tests de sécurité API sont la pratique consistant à tester systématiquement vos endpoints API pour détecter les vulnérabilités, les contournements d'authentification, l'exposition des données, les attaques par injection et les failles de logique métier. Ce guide couvre l'OWASP API Security Top 10, les techniques de test pratiques avec des exemples de code, les meilleurs outils disponibles et une liste de contrôle complète à suivre.

Que vous soyez un développeur qui construit des APIs, un ingénieur QA qui valide la sécurité ou un responsable DevSecOps qui implémente la sécurité shift-left, ce guide vous fournit des techniques pratiques pour sécuriser vos APIs.

OWASP API Security Top 10 (2023)

L'OWASP API Security Top 10 est le cadre standard de l'industrie pour les risques de sécurité API. Voici chaque vulnérabilité avec les techniques de test :

API1 : Autorisation défaillante au niveau des objets (BOLA)

La vulnérabilité API la plus courante. Un attaquant manipule les identifiants d'objets dans les requêtes pour accéder aux données d'autres utilisateurs.

Comment tester :

# Se connecter en tant qu'utilisateur A, obtenir ses ressources
curl -X GET https://api.example.com/users/101/orders \
  -H "Authorization: Bearer USER_A_TOKEN"
# Retourne les commandes de l'utilisateur A ✓
# Essayez maintenant d'accéder aux ressources de l'utilisateur B avec le token de l'utilisateur A
curl -X GET https://api.example.com/users/102/orders 

-H "Authorization: Bearer USER_A_TOKEN"
# Doit retourner 403 Forbidden, pas les commandes de l'utilisateur B

Correction : Vérifiez toujours que l'utilisateur authentifié possède (ou a la permission d'accéder à) la ressource demandée. Ne vous fiez jamais aux seuls identifiants fournis par le client.

API2 : Authentification défaillante

Des mécanismes d'authentification faibles qui permettent aux attaquants de compromettre les tokens, les clés ou les mots de passe.

Ce qu'il faut tester :

• Peut-on accéder aux endpoints protégés sans token ? (Devrait obtenir 401)
• L'API accepte-t-elle des tokens expirés ?
• Y a-t-il une limitation de débit sur les tentatives de connexion ?
• Les tokens sont-ils invalidés lors de la déconnexion ou du changement de mot de passe ?
• Le token est-il stocké de manière sécurisée (cookies HttpOnly, pas localStorage) ?

# Test : pas d'en-tête d'authentification
curl -X GET https://api.example.com/users/me
# Attendu : 401 Unauthorized
# Test : token expiré
curl -X GET https://api.example.com/users/me 

-H "Authorization: Bearer EXPIRED_TOKEN_HERE"
# Attendu : 401 Unauthorized
# Test : protection contre la force brute (tentatives de connexion rapides)
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" 

-X POST https://api.example.com/auth/login 

-d '{"email":"victim@example.com","password":"guess'$i'"}'
done
# Attendu : 429 Too Many Requests après plusieurs tentatives

API3 : Autorisation défaillante au niveau des propriétés d'objet

L'API expose des propriétés d'objet sensibles qui devraient être cachées ou en lecture seule.

Comment tester :

# Test : un utilisateur ordinaire peut-il définir des champs réservés aux administrateurs ?
curl -X PATCH https://api.example.com/users/101 \
  -H "Authorization: Bearer REGULAR_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "isVerified": true}'
# Attendu : "role" et "isVerified" doivent être ignorés ou retourner 403

API4 : Consommation de ressources sans restriction

L'API ne limite pas les taux de requêtes, les tailles de charge utile ou les opérations gourmandes en ressources.

Ce qu'il faut tester :

• Envoyer des charges utiles surdimensionnées (corps JSON de 100 Mo)
• Demander de très grandes tailles de page (GET /users?limit=1000000)
• Déclencher des opérations coûteuses de manière répétée
• Télécharger des fichiers excessivement volumineux

API5 : Autorisation défaillante au niveau des fonctions

Les utilisateurs ordinaires peuvent accéder aux endpoints API réservés aux administrateurs.

# Test : accéder aux endpoints d'administration avec un token d'utilisateur ordinaire
curl -X GET https://api.example.com/admin/users \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"
# Attendu : 403 Forbidden
curl -X DELETE https://api.example.com/admin/users/102 

-H "Authorization: Bearer REGULAR_USER_TOKEN"
# Attendu : 403 Forbidden

API6 : Accès sans restriction aux flux métier sensibles

Abus automatisé de fonctionnalités métier légitimes : scalping, spam, abus de coupons.

API7 : Falsification de requête côté serveur (SSRF)

L'API récupère des URLs externes fournies par l'utilisateur sans validation, permettant aux attaquants d'analyser les réseaux internes.

# Test : essayer d'accéder aux services internes via un paramètre URL
curl -X POST https://api.example.com/fetch-url \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'
# Doit être bloqué, cible les métadonnées AWS
curl -X POST https://api.example.com/fetch-url 

-d '{"url": "http://localhost:6379/"}'
# Doit être bloqué, cible le Redis interne

API8 : Mauvaise configuration de sécurité

En-têtes de sécurité manquants, messages d'erreur trop verbeux, méthodes HTTP inutiles activées.

# Test : vérifier les en-têtes de sécurité
curl -I https://api.example.com/users
# Vérifier que ces en-têtes sont présents :
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# Strict-Transport-Security: max-age=31536000
# Content-Security-Policy: default-src 'self'
# Test : vérifier les messages d'erreur trop verbeux
curl -X GET https://api.example.com/users/invalid
# NE DOIT PAS exposer les traces de pile, les détails de la base de données ou les chemins internes

API9 : Gestion inadéquate de l'inventaire

Anciennes versions d'API encore accessibles, endpoints non documentés exposés, endpoints de développement ou de staging laissés publics.

Ce qu'il faut tester : Essayez d'accéder à /api/v1/ quand /api/v2/ est la version actuelle. Vérifiez les chemins courants comme /debug, /swagger, /graphql, /actuator.

API10 : Consommation non sécurisée d'APIs

L'API fait confiance aveuglément aux données provenant d'APIs tierces sans validation.

Outils de tests de sécurité API

OWASP ZAP (Zed Attack Proxy)

Outil de test de sécurité gratuit et open source maintenu par OWASP. Il peut analyser automatiquement les APIs pour détecter les vulnérabilités courantes.

# Exécuter ZAP contre votre API avec le scan API
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r report.html

Burp Suite

L'outil de référence pour les tests de sécurité web et API. Burp Suite Professional offre des analyses automatisées, un intruder (fuzzing) et un repeater pour les tests manuels.

Postman avec scripts de sécurité

Vous pouvez ajouter des scripts de test de sécurité à vos collections Postman existantes :

// Script de test Postman pour les vérifications de sécurité
pm.test("Pas de données sensibles dans la réponse", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("password");
  pm.expect(body).to.not.include("ssn");
  pm.expect(body).to.not.include("credit_card");
});
pm.test("En-têtes de sécurité présents", () => {
pm.expect(pm.response.headers.get("X-Content-Type-Options")).to.equal("nosniff");
pm.expect(pm.response.headers.get("Strict-Transport-Security")).to.exist;
});
pm.test("Pas de divulgation de version serveur", () => {
pm.expect(pm.response.headers.get("Server")).to.not.include("Apache/2.4");
pm.expect(pm.response.headers.get("X-Powered-By")).to.not.exist;
});

Qodex.ai

Qodex.ai inclut des tests de sécurité intégrés qui analysent automatiquement vos APIs pour les vulnérabilités OWASP Top 10. L'agent IA génère des cas de test de sécurité aux côtés des tests fonctionnels, couvrant les contournements d'authentification, les attaques par injection et l'exposition des données, sans nécessiter d'expertise en sécurité.

Nuclei

Scanner de vulnérabilités rapide et basé sur des templates. Des milliers de templates contribués par la communauté pour les tests de sécurité API.

# Scanner une API pour les vulnérabilités connues
nuclei -u https://api.example.com -t api/ -severity critical,high

Comparaison des outils

Liste de contrôle des tests de sécurité API

Utilisez cette liste de contrôle pour chaque API que vous construisez ou révisez :

Authentification

• Tous les endpoints nécessitent une authentification (sauf les publics)
• Les tokens expirent dans un délai raisonnable
• La rotation des refresh tokens est implémentée
• Les tentatives de connexion échouées sont soumises à une limitation de débit
• Les flux de réinitialisation de mot de passe sont sécurisés
• Les clés API ne sont pas exposées dans les URLs (utiliser les en-têtes)

Autorisation

• Autorisation au niveau des objets sur chaque endpoint (protection BOLA)
• Autorisation au niveau des fonctions (endpoints d'administration restreints)
• Autorisation au niveau des propriétés (champs sensibles protégés)
• L'autorisation ne peut pas être contournée en changeant la méthode HTTP

Validation des entrées

• Toutes les entrées sont validées (type, longueur, format, plage)
• Protection contre l'injection SQL (requêtes paramétrées)
• Protection contre l'injection NoSQL
• Limites de taille du corps de requête imposées
• Validation des téléchargements de fichiers (type, taille, contenu)

Protection des données

• HTTPS imposé (en-tête HSTS présent)
• Données sensibles non exposées dans les réponses (mots de passe, tokens, PII)
• Données sensibles non journalisées
• CORS configuré de manière restrictive
• En-têtes de réponse empêchant la mise en cache des données sensibles

Limitation de débit et régulation

• Limites de débit sur tous les endpoints
• Limites plus strictes sur les endpoints d'authentification
• En-têtes de limite de débit retournés (X-RateLimit-*)
• Code de statut 429 retourné lorsque les limites sont dépassées

Intégrer les tests de sécurité dans CI/CD

Les tests de sécurité doivent être automatisés et exécutés à chaque modification de code, pas seulement avant les releases.

# GitHub Actions, scan de sécurité API
name: API Security Tests
on:
  push:
    branches: [main, develop]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
  - name: Démarrer le serveur API
    run: docker-compose up -d

  - name: Attendre l'API
    run: npx wait-on http://localhost:3000/health

  - name: Exécuter le scan OWASP ZAP
    uses: zaproxy/action-api-scan@v0.7.0
    with:
      target: http://localhost:3000/openapi.json
      rules_file_name: .zap/rules.tsv
      fail_action: true

  - name: Exécuter les tests de sécurité personnalisés
    run: npm run test:security

  - name: Télécharger le rapport de sécurité
    if: always()
    uses: actions/upload-artifact@v4
    with:
      name: security-report
      path: zap-report.html

À lire aussi : How to Get a Rugcheck API Key and Start Using the API

Construire une stratégie de tests API axée sur la sécurité

Les tests de sécurité API fonctionnent mieux lorsqu'ils sont combinés avec d'autres types de tests :

• Tests fonctionnels : Vérifier le comportement correct (guide des tests REST API)
• Tests de charge : Vérifier les performances sous pression (guide des tests de charge API)
• Tests d'intégration : Vérifier les interactions entre services (guide des tests d'intégration API)
• Tests de sécurité : Vérifier la protection contre les attaques (ce guide)

Pour une vue d'ensemble complète de tous les outils de test disponibles, consultez notre comparaison des outils de test API.

Foire aux questions

Qu'est-ce que les tests de sécurité API ?

Les tests de sécurité API sont le processus de test de vos endpoints API pour détecter les vulnérabilités, les contournements d'authentification, les attaques par injection, l'exposition des données et les failles d'autorisation. L'objectif est d'identifier et de corriger les faiblesses de sécurité avant que les attaquants ne les exploitent.

Qu'est-ce que l'OWASP API Security Top 10 ?

L'OWASP API Security Top 10 est une liste des risques de sécurité API les plus critiques, maintenue par l'Open Worldwide Application Security Project. Elle inclut l'Autorisation défaillante au niveau des objets (BOLA), l'Authentification défaillante, l'Autorisation défaillante au niveau des propriétés d'objet et sept autres vulnérabilités API courantes.

Comment commencer les tests de sécurité API ?

Commencez par la liste de contrôle OWASP API Security Top 10 ci-dessus. Exécutez une analyse automatisée avec OWASP ZAP contre votre spécification API. Testez ensuite manuellement l'authentification, l'autorisation et les vulnérabilités par injection. Utilisez Qodex.ai pour générer automatiquement des cas de test de sécurité à partir de votre spécification API.

Quels sont les meilleurs outils pour les tests de sécurité API ?

OWASP ZAP (gratuit, analyse automatisée), Burp Suite (tests de pénétration professionnels), Qodex.ai (génération de tests de sécurité propulsée par IA) et Nuclei (analyse basée sur des templates). La plupart des équipes utilisent une combinaison d'outils de test automatisés et manuels.

Quelle est la différence entre SAST et DAST pour les APIs ?

SAST (Static Application Security Testing) analyse le code source sans exécuter l'application. DAST (Dynamic Application Security Testing) teste l'API en cours d'exécution en envoyant des requêtes et en analysant les réponses. Les deux sont précieux : SAST détecte les problèmes de niveau code en amont, et DAST trouve les vulnérabilités d'exécution.

À quelle fréquence devrais-je exécuter des tests de sécurité API ?

Les analyses de sécurité automatisées doivent s'exécuter à chaque déploiement (dans CI/CD). Des tests de pénétration complets doivent être effectués trimestriellement ou avant les releases majeures. Surveillez continuellement les nouvelles vulnérabilités dans les dépendances à l'aide d'outils comme Dependabot ou Snyk.