Sécurité des API : du bon design à la preuve d'exploitation

Les API sont devenues l'interface principale du web : elles concentrent aujourd'hui la majorité du trafic applicatif. Dans ce paysage, l'attaque logique a remplacé l'exploit technique — autorisations mal calibrées, consommation illimitée de ressources, exfiltration silencieuse. La défense efficace ne tient plus au seul pare-feu applicatif, mais à un cycle continu : un design sûr, des tests qui bloquent, et une observabilité en production.

Le vrai périmètre d'attaque : vos propres contrats d'API

La plupart des incidents récents ne viennent ni d'une faille zero-day, ni d'un framework obscur, mais de deux entrées majeures de l'OWASP API Security Top 10 : l'autorisation cassée au niveau de l'objet et l'exposition excessive de propriétés.

Traduit en termes métier : un utilisateur parfaitement légitime peut lire ou modifier ce qu'il ne devrait pas, parce que la ressource, son identifiant et ses champs ne sont pas protégés au bon niveau.

Ajoutez à cela des ressources non bornées — absence de limitation de débit, pagination facultative — et l'API se transforme en vecteur de déni de service à bas bruit.

L'API est devenue l'interface de votre logique métier. La sécuriser, c'est sécuriser vos décisions.

Ce qui fonctionne côté conception

• Authentification et autorisation. OAuth2/OIDC en Authorization Code avec PKCE, jetons courts et rotation des refresh tokens, portées fines par ressource et par action.
• mTLS entre services. Par défaut avec Linkerd, automatisé côté Istio en démarrant en mode permissif puis en verrouillant progressivement.
• Contrats stricts. OpenAPI 3.1 et JSON Schema : validation des entrées et des sorties, champs interdits, valeurs bornées.
• Limites explicites. Limitation de débit, tailles maximales de corps et d'en-têtes, clé d'idempotence sur les écritures. Attention : un plafond par adresse IP n'est pas un plafond par utilisateur ni par clé d'API.

Du test qui rassure au test qui bloque

Le déplacement des contrôles vers l'amont ne vaut que s'il conditionne la mise en production : si le contrôle échoue, rien ne part.

• Analyse statique (Semgrep, Sonar) pour les secrets et les injections.
• Lint de la spécification (Spectral) : règles OWASP codifiées, ruptures de compatibilité détectées avant le merge.
• Tests contractuels (Pact, Spring Cloud Contract) : producteur et consommateur synchronisés par le contrat.
• Tests dynamiques et fuzzing (OWASP ZAP, Burp) sur des environnements éphémères.
• Tests d'autorisation dédiés : parcours nominal, puis tentatives de contournement — accès à l'objet d'un autre utilisateur, escalade de privilèges.

Ce pipeline n'a de valeur que s'il applique des seuils : zéro vulnérabilité critique, un nombre plafonné de vulnérabilités hautes, une couverture sécurité d'au moins 80 % des endpoints.

À l'exécution, la vérité des métriques

La défense en production n'est pas un pare-feu applicatif miraculeux, c'est une télémétrie exploitable qui déclenche des décisions automatiques.

• Passerelle et WAF : limitation de débit adaptative, jeu de règles OWASP Core Rule Set, coupe-circuits qui protègent le backend et dégradent proprement le service.
• Traces distribuées. Chaque requête porte son identifiant de trace et des attributs de sécurité — identifiant utilisateur, portées, décision de politique, taille de requête. Ce sont eux qui rendent un incident rejouable.
• Journaux structurés et piste d'audit : qui, quoi, quand, depuis quelle adresse, corrélés aux traces.
• Métriques orientées sécurité : taux de 401 et 403, latence par endpoint et par utilisateur, erreurs de validation, et alertes comportementales sur les pics de refus ou l'énumération d'identifiants.

Un WAF bien réglé voit un motif d'attaque. L'observabilité applicative, elle, voit une intention.

Ce qui relève de l'hygiène, et qu'on oublie trop

• Secrets : coffre centralisé, rotation automatique, interdiction stricte des secrets en configuration.
• CORS et en-têtes : origines explicites, gestion maîtrisée des cookies, HSTS et CSP.
• Versioning : sémantique, dépréciations annoncées 6 à 12 mois à l'avance et suivies dans les métriques.
• Tests d'intrusion : réguliers pour les API publiques, avec un périmètre et des délais de correction clairs.

Trois décisions à prendre cette semaine

1. Figer les règles d'autorisation au niveau de l'objet et de ses propriétés.
2. Rendre les limites mesurables : plafonds par IP, par utilisateur et par clé, tailles maximales, pagination — le tout testé en intégration continue.
3. Enrichir les traces avec l'identifiant utilisateur, les portées et la décision de politique.

Conclusion

La sécurité des API n'est plus un empilement d'outils, c'est un système de preuves : un design qui interdit par défaut, des tests qui empêchent les régressions, des mesures qui racontent ce qui se passe réellement en production. À ce prix, une API cesse d'être un angle mort et devient un actif observable — donc maîtrisable.

Sources

• OWASP API Security Top 10 (2023)
• Spécifications OpenAPI 3.1 et JSON Schema
• RFC 9700 — OAuth 2.0 Security Best Current Practice
• Documentation Istio et Linkerd (mTLS)
• OWASP Core Rule Set
• OpenTelemetry — traces et conventions d'attributs