Qu'est-ce qu'un Audit de Sécurité d'API ?

Qu'est-ce qu'un audit de sécurité d'API ?

Un audit de sécurité d'API est l'examen systématique de la surface d'API d'une organisation pour les vulnérabilités — faiblesses d'authentification, défauts d'autorisation, gaps de validation d'entrée, gaps de rate-limiting, données sensibles exposées et le reste de l'OWASP API Security Top 10. L'audit produit une liste priorisée de findings avec sévérité, complexité d'exploit et guidage de remédiation. Bien fait, un audit de sécurité d'API est le moyen le plus efficace de faire ressortir le risque réel dans un stack web moderne — la plupart des apps modernes sont à 80%+ surface d'API, donc les APIs concentrent l'exposition de sécurité.

Les audits de sécurité d'API viennent en trois saveurs : internes (votre équipe sécurité exécutant des outils + revue manuelle), tiers (firmes spécialistes comme NCC Group, Bishop Fox, Trail of Bits — généralement annuels ou pré-lancement) et continus automatisés (outils comme Salt, Noname, Wallarm scannant le trafic de production en continu). La plupart des orgs matures utilisent les trois : continu automatisé pour la baseline, tiers annuellement pour la profondeur, interne pour la remédiation continue.

L'OWASP API Security Top 10 (édition 2023)

La liste de référence contre laquelle chaque audit de sécurité d'API vérifie :

1. Broken Object Level Authorization (BOLA) — vuln API la plus courante. GET /users/123 renvoie les données de l'utilisateur 123 sans vérifier que l'appelant est autorisé.
2. Broken Authentication — validation faible de token, réutilisation d'identifiants, MFA manquant.
3. Broken Object Property Level Authorization — l'appelant peut lire ou modifier des champs d'objet qu'il ne devrait pas.
4. Unrestricted Resource Consumption — pas de rate limiting, pas de cap de taille de body ; permet le DoS.
5. Broken Function Level Authorization — endpoints admin accessibles aux non-admins.
6. Unrestricted Access to Sensitive Business Flows — l'automatisation peut vider l'inventaire, abuser des coupons, etc.
7. Server-Side Request Forgery (SSRF) — URL contrôlée par l'utilisateur récupérée côté serveur atteint des services internes.
8. Security Misconfiguration — mode debug en prod, identifiants par défaut, erreurs verbeuses.
9. Improper Inventory Management — anciennes versions d'API tournant sans monitoring ("APIs cachées").
10. Unsafe Consumption of APIs — APIs tierces faites confiance sans validation.

Ce que couvre un audit de sécurité d'API

Authentification + autorisation

• Validation de token : signature, expiration, scope, audience.
• Gestion de session : rotation, révocation, idle timeout.
• Vérifications d'autorisation à chaque endpoint, incluant niveau objet (BOLA).
• Limites de rôles + permissions appliquées de manière cohérente.

Validation d'entrée

• SQL injection, NoSQL injection, command injection, LDAP injection.
• SSRF / XXE / risques de désérialisation.
• Limites de taille de body + application du content-type.
• Validation de schéma JSON.

Rate limiting + prévention d'abus

• Rate limits par utilisateur / par IP / par endpoint.
• Protection brute-force sur les endpoints d'auth.
• CAPTCHA + détection de bots quand approprié.

Exposition de données

• Response shaping (ne pas renvoyer de hashes de mots de passe, IDs internes).
• Discipline de logging (ne pas logger tokens, PII).
• Hygiène des messages d'erreur (ne pas faire fuir stack traces, plans de query).

Inventaire + cycle de vie

• Cataloguer tous les endpoints (incluant v1, v2, internes). Voir API sprawl.
• Sunset les anciennes versions selon planning.
• Détecter les APIs cachées (déployées sans passer par la passerelle).

Comment se déroule un audit typique

1. Phase d'inventaire. Cataloguer toutes les APIs (logs de passerelle, specs OpenAPI, grep de code, découverte de trafic).
2. Scan automatisé. Outils comme OWASP ZAP, Burp Suite Pro, StackHawk, Salt exécutent des tests automatisés.
3. Tests manuels. Les auditeurs ciblent manuellement l'OWASP Top 10 — les outils automatisés ratent BOLA, abus de logique métier et flux d'auth complexes.
4. Findings + scoring de sévérité. CVSS ou scoring de risque propriétaire ; généralement CRITICAL/HIGH/MEDIUM/LOW.
5. Remédiation. Corrections d'ingénierie, avec suivi jusqu'à vérification.
6. Re-test. Vérifier que les findings sont réellement fermés ; courant de trouver des régressions.
7. Rapport. Résumé interne + exécutif ; parfois un résumé public sanitisé pour revue client/régulateur.

Findings courants d'audit de sécurité d'API

• BOLA sur ressources REST. Mass assignment / exposition directe d'ID sans vérifications d'accès.
• Erreurs verbeuses faisant fuir stack traces. La production ne devrait jamais exposer de stack traces internes.
• Rate limiting uniquement à la passerelle. Si les utilisateurs peuvent frapper l'origine directement, les rate limits sont sans signification.
• Gaps de validation JWT. Sauter la vérification de signature, accepter alg: none, clés HMAC faibles.
• Mishandling de scope OAuth. Le token accorde plus d'accès que prévu ; les refresh tokens n'expirent jamais.
• TLS manquant sur les appels internes. À l'intérieur du VPC ≠ sécurisé ; les appels internes méritent mTLS ou au moins TLS authentifié.
• Désérialisation non sécurisée. Particulièrement dans les anciens chemins pickle Java / .NET / Python.
• Protections CORS / CSRF manquantes sur les endpoints orientés navigateur.

FAQ : Audits de Sécurité d'API

À quelle fréquence devrais-je lancer un audit de sécurité d'API ?

Scan automatisé continu tout le temps. Revue interne par release. Tiers annuellement + avant tout lancement majeur. Ne vous reposez pas seulement sur l'annuel — les APIs changent trop vite.

Quelle est la différence entre un audit de sécurité d'API et un pen test ?

Le penetration testing est plus large (réseau, infrastructure, ingénierie sociale). Un audit de sécurité d'API est spécifique aux APIs. La plupart des entreprises lancent les deux — pen tests annuellement, audits API par release/continus.

Combien de temps prend un audit de sécurité d'API ?

Interne automatisé : heures. Tiers exhaustif : 2-6 semaines pour une surface d'API SaaS typique. Le temps s'échelonne avec le nombre d'API + la complexité.

Combien coûte un audit de sécurité d'API ?

Tiers exhaustif : 20k-200k $ selon la portée + la réputation de la firme. Outils continus automatisés : 20k-200k $/an. Travail interne : variable.

Comment me préparer pour un audit ?

Specs OpenAPI à jour, inventaire API actuel, threat model récent, liste des issues connus, accès pour les auditeurs (identifiants de test, accès passerelle, repo de code). Les auditeurs détestent partir de zéro.

Et les APIs internes uniquement ?

Auditez-les aussi. "Interne" ne signifie pas sécurisé — la plupart du mouvement latéral dans les violations passe par les APIs internes. Appliquez les mêmes standards.

Comment l'audit de sécurité d'API se rapporte-t-il à SOC 2 / ISO 27001 ?

Les deux frameworks exigent une forme de gestion des vulnérabilités, souvent satisfaite par une cadence d'audit de sécurité d'API documentée. Les auditeurs demanderont des preuves de tests + remédiation réguliers.

Comment LoadFocus se rapporte à la validation de sécurité d'API

Les audits de sécurité d'API font ressortir les vulnérabilités à un point dans le temps. Le monitoring d'API LoadFocus valide la santé continue — incluant les vérifications d'assertion qui attrapent les régressions dans la gestion auth/authz (par ex., un déploiement qui casse silencieusement la protection BOLA). Les tests de charge d'API valident que le rate-limiting et la protection DoS fonctionnent réellement sous des patterns de charge similaires aux attaques — beaucoup de rate limits ont l'air corrects en revue de code mais échouent à l'échelle.