Sécurité des API REST : guide OWASP API Top 10 pour 2026

Les API représentent aujourd'hui plus de 83% du trafic web mondial selon Akamai (2024) et constituent la cible n°1 des cyberattaques. En 2023, Gartner estimait que les attaques d'API deviendraient le vecteur d'attaque le plus fréquent, devant le phishing. Voici le guide définitif pour sécuriser vos API REST et GraphQL en 2026.

1. Pourquoi les API sont devenues la cible n°1

Avec la généralisation des architectures microservices, du serverless et du mobile-first, les API exposent désormais directement la logique métier et les données sensibles. Les brèches récentes (T-Mobile 37M clients, Optus 9.8M, Twitter 5.4M comptes) ont toutes pour origine une API mal sécurisée.

• Surface d'attaque massive : une entreprise gère en moyenne 15 000 API actives (Salt Security 2024).
• Shadow API : 30% des API ne sont pas documentées et échappent aux contrôles.
• Logique métier exposée : authentification, paiement, données personnelles directement accessibles.
• Outils d'attaque automatisés : Postman, Burp Suite, scripts Python rendent l'exploitation triviale.

2. OWASP API Security Top 10 (édition 2023)

L'OWASP a publié en 2023 une nouvelle édition de son Top 10 spécifique aux API. Voici les 10 vulnérabilités à connaître absolument.

API1:2023 — Broken Object Level Authorization (BOLA)

N°1 du Top 10. Un utilisateur peut accéder aux objets d'un autre simplement en modifiant l'identifiant dans l'URL :/api/orders/12345 → /api/orders/12346. Solution : vérifier systématiquement la propriété de l'objet côté serveur, jamais se fier à des IDs côté client.

API2:2023 — Broken Authentication

Tokens JWT mal validés, secrets faibles, absence de rotation, brute force possible. Imposer OAuth 2.0 + PKCE, JWT signés RS256, MFA obligatoire pour les API admin.

API3:2023 — Broken Object Property Level Authorization

Un utilisateur peut modifier des champs sensibles non autorisés (ex: "role": "admin" dans un PATCH). Utiliser des DTO explicites et le mass-assignment protection (Rails, Laravel, Spring).

API4:2023 — Unrestricted Resource Consumption

Pas de rate limiting → DDoS, scraping, explosion des coûts cloud. Mettre en place : rate limiting (100 req/min par IP), quotas par token, timeout, payload max 1MB.

API5:2023 — Broken Function Level Authorization

Endpoints admin (/api/admin/users) accessibles aux utilisateurs standards. Implémenter du RBAC strict, tester chaque endpoint avec différents rôles.

API6:2023 — Unrestricted Access to Sensitive Business Flows

Nouveau dans le Top 10. Exemple : achat illimité de billets de concert par bot. Mettre en place CAPTCHA, device fingerprinting, détection comportementale.

API7:2023 — Server Side Request Forgery (SSRF)

L'API accepte une URL fournie par l'utilisateur et la requête côté serveur (ex: import d'image distante) → accès au métadonnées EC2, scan réseau interne. Whitelister les domaines, bloquer les IP privées (169.254.169.254, 10.0.0.0/8).

API8:2023 — Security Misconfiguration

CORS trop permissif (Access-Control-Allow-Origin: *), headers de sécurité absents, debug activé en prod. Utiliser Helmet.js, scanner Nikto, configuration as code.

API9:2023 — Improper Inventory Management

Anciennes versions d'API (v1, v2 dépréciées) toujours en ligne et non patchées. Maintenir un inventaire (Postman, Swagger Hub), déprécier proprement avec sunset header.

API10:2023 — Unsafe Consumption of APIs

Confiance aveugle dans les API tierces (paiement, géoloc). Valider toutes les réponses, gérer les timeouts, ne jamais exposer directement les données externes.

3. Architecture sécurisée d'une API moderne

3.1 Authentification : OAuth 2.0 + OIDC

Standard de facto. Flow recommandé :

• Authorization Code + PKCE pour les apps web et mobiles.
• Client Credentials pour la communication service-to-service.
• Tokens JWT courts (15 min) + refresh tokens (7 jours).
• Providers recommandés : Auth0, Okta, AWS Cognito, Keycloak (open source).

3.2 API Gateway : la première ligne de défense

Toute API publique DOIT passer par une gateway centralisée :

• AWS API Gateway / WAF : intégré, scalable.
• Kong : open source, plugins riches.
• Apigee (Google) : enterprise, analytics avancé.
• Cloudflare API Shield : edge, anti-DDoS, ML.

Fonctions clés : authentification, rate limiting, transformation, logging, schema validation OpenAPI.

3.3 Validation des entrées

Utiliser des schémas OpenAPI 3.1 ou JSON Schema validés au runtime (Ajv, Zod, Pydantic). Refuser tout champ inattendu (additionalProperties: false).

4. Sécurité des API GraphQL

GraphQL apporte ses propres défis :

• Query depth limiting : bloquer les requêtes trop profondes (max 10 niveaux).
• Query complexity analysis : pondérer chaque champ pour éviter les requêtes coûteuses.
• Désactiver l'introspection en production (révèle tout le schéma).
• Persisted queries : seules les requêtes pré-approuvées sont autorisées.

5. Tests de sécurité d'API : la stack 2026

5.1 SAST / DAST

• 42Crunch : audit OpenAPI, scan continu.
• StackHawk : DAST orienté API, intégration CI/CD.
• Burp Suite Pro : référence pour les pentests manuels.
• OWASP ZAP : open source, automatisable.

5.2 API Security Testing en CI/CD

Intégrer dans le pipeline (cf. guide DevSecOps ) :

• Validation du contrat OpenAPI à chaque PR.
• Tests d'autorisation automatisés (différents rôles).
• Fuzzing API avec RESTler ou Schemathesis.
• Scan secrets dans les specs (clés API hardcodées).

6. Monitoring et détection runtime

Une API sécurisée à la conception ne suffit pas. Il faut détecter les attaques en temps réel :

• WAF nouvelle génération : Cloudflare, AWS WAF, F5 avec règles OWASP CRS.
• API Security Platforms : Salt Security, Noname Security, Traceable AI.
• Anomaly detection : ML pour détecter usages anormaux (volume, géoloc, séquences).
• Logging structuré : tous les appels avec user_id, IP, latence dans un SIEM.

7. Checklist : 12 mesures prioritaires

1. Inventaire complet des API (Swagger/OpenAPI à jour).
2. Authentification OAuth 2.0 + MFA pour les endpoints sensibles.
3. Rate limiting global et par utilisateur.
4. Validation stricte des inputs (schema OpenAPI au runtime).
5. HTTPS obligatoire (TLS 1.3), HSTS activé.
6. Headers de sécurité (CORS strict, CSP, X-Content-Type-Options).
7. Logging exhaustif vers SIEM avec corrélation.
8. Tests d'autorisation automatisés en CI/CD.
9. Pentest API annuel par un cabinet certifié.
10. Plan de rotation des clés API et tokens (max 90 jours).
11. Monitoring des Shadow API via discovery automatique.
12. Formation des développeurs au Secure Coding API.

8. Conclusion

La sécurité des API n'est plus une option : elle conditionne la survie business. Une approche structurée — OAuth, gateway, validation, monitoring — combinée à la culture DevSecOps réduit drastiquement le risque. Chez CloudSecure, nous auditons votre exposition API, détectons le Shadow IT et formons vos équipes aux bonnes pratiques OWASP. Articles complémentaires : DevSecOps, Zero Trust, Pentest entreprise.