Sécurité des API : comment passer du « bon design » à la preuve d’exploitation

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

La plupart des incidents récents ne viennent ni d’un 0-day, ni d’un framework obscur, mais d’autorisation cassée et d’exposition de propriétés d’objets : deux entrées majeures de l’OWASP API Security Top 10 (2023). Traduction métier : un utilisateur “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 rate limiting, pagination facultative) : l’API se transforme en DDoS à bas bruit.

Ce qui marche côté conception (sans religion d’outil)

• AuthN/AuthZ : OAuth2/OIDC en Authorization Code + PKCE, tokens courts et refresh rotatif ; scopes fins par ressource et action. Les dernières BCP OAuth (RFC 9700) fixent la barre.
• mTLS entre services : par défaut dans Linkerd et automatisé côté Istio (mode PERMISSIVE → verrouillage progressif).
• Contrats stricts : OpenAPI 3.1 + JSON Schema (validation entrées/sorties, champs interdits, valeurs bornées).
• Limites explicites : rate limiting (token bucket / sliding window), tailles de corps/headers, idempotence (clé d’idempotence sur POST/PATCH). Un plafond par IP ≠ un plafond par utilisateur ou par clé.

Du “test qui rassure” au test qui bloque

Le shift-left utile se mesure au gating en CI : si ça échoue, rien ne part en prod.

• SAST (Semgrep/Sonar) pour secrets/injections et failles récurrentes.
• Lint OpenAPI (Spectral) : schémas et règles OWASP codifiées, breaking changes détectées avant merge.
• Tests contractuels (Pact, Spring Cloud Contract) : producteur/consommateur synchronisés par le contrat.
• DAST & fuzzing (OWASP ZAP, Burp) sur environnements éphémères.
• Tests d’autorisation dédiés : parcours happy path + tentatives de contournement (BOLA/BOPLA, escalade de privilèges).

Ce pipeline n’a de valeur que s’il bloque sur seuil : critiques = 0, hauts < N, coverage sécurité ≥ 80 % des endpoints. Les organisations matures exposent ces rapports dans leur portail dev (Backstage plugin), pour rendre la qualité visible et inévitable.

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

La défense shift-right n’est pas un WAF miracle, c’est une télémétrie exploitable et des décisions automatiques.

• Passerelle & WAF : rate limiting adaptatif, OWASP Core Rule Set (injections/XSS/SSRF), threat intel (listes IP, réputation), circuit breakers qui protègent le backend et dégradent proprement.
• Traces distribuées (OpenTelemetry) : chaque requête porte trace_id/span_id et des attributs sécurité (user_id, scopes, policy_decision, request_size). Ces attributs rendent chaque incident rejouable.
• Logs structurés & audit trail : who/what/when/from_ip, corrélés aux traces.
• Métriques orientées sécu : taux 401/403, latence par endpoint et par user, erreurs de validation ; alertes comportementales (spikes 403, énumération d’IDs, balayage d’URL).

WAF/CRS bien réglé ≠ panacée : Akamai observe 311 milliards d’attaques web & API en 2024 (+33 % YoY). Sans visibilité applicative, un WAF voit un motif ; l’observabilité voit une intention.

Trois décisions à prendre cette semaine

• Figez vos règles d’autorisation au niveau de l’objet et de ses propriétés (BOLA/BOPLA).
• Rendez vos limites mesurables : plafonds par IP, par utilisateur et par clé ; tailles maximales ; pagination — testés en CI.
• Faites parler vos traces : ajoutez user_id, scopes, policy_decision, request_size/response_size aux spans HTTP.

Conclusion

La sécurité des API n’est plus un empilement d’outils mais 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 en production. À ce prix, vos APIs cessent d’être un angle mort et deviennent un actif observable — donc maîtrisable.