Qu'est-ce que la sécurité des API ?

Qu'est-ce que la sécurité des API ?

La sécurité des API regroupe les contrôles qui garantissent qu'une API ne renvoie que les données, et n'exécute que les actions, qu'un client vérifié a le droit d'utiliser. Elle combine authentification, autorisation, chiffrement en transit, validation des entrées et limitation de débit, appuyés par la surveillance. Comme la plupart des applications communiquent par API, l'API est souvent la principale surface d'attaque.

Comment fonctionne la sécurité des API

Aucun contrôle ne suffit seul : chaque requête traverse donc plusieurs couches, qui répondent chacune à une question différente :

• Authentification : qui appelle ? Une clé d'API, un jeton d'accès OAuth 2.0 (envoyé comme bearer token), un JWT signé ou un certificat client (mTLS). Mieux vaut des identifiants de courte durée, à portée limitée, absents du code côté client et du dépôt de sources.
• Autorisation : que peut faire l'appelant ? Vérifiée côté serveur pour chaque requête et chaque objet, jamais déduite d'un rôle ou d'un identifiant envoyé par le client.
• Chiffrement : quelqu'un peut-il lire en chemin ? TLS sur tout le trafic, certificats validés et renouvelés à temps.
• Validation des entrées : cette requête est-elle sûre à traiter ? Contrôlez type, longueur, format et plage selon un schéma strict, et rejetez les champs inconnus.
• Limitation de débit (rate limiting) : à partir de quand est-ce trop ? Des limites par client et par endpoint freinent la force brute, le scraping et l'abus d'endpoints coûteux.

Exemple : autorisation défaillante au niveau de l'objet

La faille grave la plus courante est un serveur qui authentifie l'appelant sans jamais vérifier à qui appartient l'objet. Il suffit de changer un identifiant dans l'URL :

GET /api/orders/1001   (token of user A)  -> 200 OK, A's order
GET /api/orders/1002   (token of user A)  -> 200 OK, B's order  <- broken object level authorization
GET /api/orders/1002   (token of user A)  -> 403 Forbidden      <- what the server should answer

Authentification et autorisation

L'OWASP API Security Top 10 (2023)

L'OWASP API Security Top 10 est la liste de référence que la plupart des équipes utilisent pour prioriser. L'édition 2023 comprend : broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server side request forgery, security misconfiguration, improper inventory management et unsafe consumption of APIs. Notre entrée sur les principaux risques de sécurité des API les passe en revue, et attaques d'API explique comment elles sont exploitées.

Erreurs courantes en sécurité des API

• Faire confiance au client : un rôle, un identifiant d'utilisateur ou un prix reçu dans le corps de la requête.
• Renvoyer des objets entiers de la base de données et masquer des champs dans le front.
• Laisser tourner d'anciennes versions d'API et des endpoints non documentés.
• Mettre des clés ou des jetons dans des applications mobiles, des bundles JavaScript ou l'historique Git.
• S'en remettre au seul gateway ou WAF. C'est une couche périmétrique utile, mais elle ne sait pas qui doit voir quel enregistrement.
• Fixer des limites de débit sans jamais vérifier ce que fait l'API quand elles sont atteintes.

Tester et surveiller la sécurité des API

Combinez les couches : analyse statique et contrôle des dépendances dans le pipeline, tests dynamiques et fuzzing sur une API en fonctionnement, tests ciblés qui tentent d'atteindre les données d'un autre locataire, et tests d'intrusion périodiques. Pour le volet revue, voir audit de sécurité d'API.

LoadFocus n'est pas un scanner de vulnérabilités, mais deux volets du sujet lui conviennent. Les tests de charge montrent comment une API et ses limites de débit se comportent sous fort trafic avant que la production ne le fasse (scripts JMeter et k6, 25 régions cloud) ; voir causes courantes du rate limiting des API et tester des API protégées par OAuth 2.0. La surveillance d'API exécute des contrôles planifiés (gratuits : toutes les 5 minutes) qui vérifient le code de statut, les en-têtes et le corps de la réponse : un endpoint de connexion qui répond soudain 200 à une mauvaise clé, ou un certificat SSL bientôt expiré, déclenche une alerte. Plus de détails dans surveillance d'API.

Questions fréquentes : sécurité des API

La sécurité des API, en termes simples ?

Tout ce qui empêche une API de partager des données ou d'exécuter des actions pour le mauvais appelant : vérifier son identité, vérifier ses droits, chiffrer le trafic, valider les entrées et limiter le débit d'utilisation.

Quelle différence entre authentification et autorisation ?

L'authentification confirme qui est le client. L'autorisation décide à quoi il peut accéder. Un système peut authentifier correctement et laisser fuiter des données si l'autorisation manque sur certains objets.

Un gateway d'API ou un WAF suffit-il ?

Non. Ils centralisent les contrôles d'authentification, la limitation de débit et le blocage par motifs, mais les failles de logique métier, comme lire la commande d'un autre, doivent être corrigées dans le service lui-même.

En quoi la limitation de débit aide-t-elle la sécurité des API ?

Elle plafonne les requêtes par client sur une fenêtre de temps, ce qui freine le credential stuffing, le scraping et l'abus d'endpoints coûteux. Testez les limites sous charge pour vérifier qu'elles tiennent et que les erreurs sont propres.

Comment tester la sécurité d'une API ?

Combinez scan automatique, fuzzing, tests d'autorisation entre locataires, tests de charge de votre limitation et test d'intrusion manuel périodique. La surveillance repère les régressions après la mise en production.