OWASP API Security Top 10

Pourquoi c'est Important

Le OWASP API Security Top 10 est le cadre de reference le plus largement utilise pour la classification des vulnerabilites API. Les equipes de securite l'utilisent pour structurer les missions de tests de penetration API. Les developpeurs l'utilisent pour valider leurs conceptions API par rapport aux patterns de risques connus. Les cadres de conformite le referencent de plus en plus comme une norme pour la posture de securite API.

Contrairement au Top 10 OWASP traditionnel pour les applications web, la liste specifique aux API se concentre sur les risques uniques qui apparaissent lorsque la logique metier est exposee a travers des interfaces programmatiques. Les API font face a des menaces distinctes car elles fonctionnent sans les contraintes d'une interface utilisateur, acceptent des donnees structurees de n'importe quel client et exposent souvent plus de fonctionnalites que prevu.

Le OWASP API Security Top 10 de 2023

API1 : Broken Object Level Authorization

La vulnerabilite API la plus courante. Elle se produit lorsqu'une API ne verifie pas que l'utilisateur demandeur a la permission d'acceder a un objet (ressource) specifique. Un attaquant modifie un identifiant dans la requete, comme un ID utilisateur ou un numero de commande, et l'API retourne les donnees appartenant a un autre utilisateur.

API2 : Broken Authentication

Faiblesses dans les mecanismes d'authentification qui permettent aux attaquants de compromettre des jetons, des cles ou des mots de passe, ou d'exploiter des failles d'implementation pour usurper l'identite d'autres utilisateurs. Couvre les problemes comme la generation faible de jetons, l'absence d'expiration des jetons, les flux de reinitialisation de mot de passe non securises et le credential stuffing sans limitation de debit.

API3 : Broken Object Property Level Authorization

Combine deux problemes lies : l'exposition excessive de donnees (l'API retourne plus de champs que ce dont le frontend a besoin) et l'affectation en masse (l'API accepte des champs que l'utilisateur ne devrait pas pouvoir modifier). Les deux proviennent du manque de validation des proprietes qu'un utilisateur devrait pouvoir lire ou ecrire.

API4 : Unrestricted Resource Consumption

Les API qui ne limitent pas correctement les ressources qu'une seule requete ou un seul utilisateur peut consommer. Couvre l'absence ou la mauvaise configuration de la limitation de debit, la pagination sans limites, l'acceptation de charges utiles volumineuses et les operations couteuses sans throttling.

API5 : Broken Function Level Authorization

Des utilisateurs qui accedent a des fonctions API reservees a d'autres roles. Un utilisateur standard qui appelle des points de terminaison d'administration, par exemple. Differe de BOLA en ce qu'il concerne les actions qu'un utilisateur peut effectuer plutot que les objets auxquels il peut acceder.

API6 : Unrestricted Access to Sensitive Business Flows

Nouveau en 2023. Les API qui exposent des flux metier sensibles (achat, reservation, commentaire) sans controles pour empecher l'abus automatise. Couvre des scenarios comme les bots de scalping de billets, la creation automatisee de comptes et le rachat massif de coupons.

API7 : Server-Side Request Forgery (SSRF)

Nouveau en 2023. Les API qui recuperent des ressources distantes basees sur des URL fournies par l'utilisateur sans valider ni restreindre la destination. Permet aux attaquants de forcer le serveur a effectuer des requetes vers des services internes, des points de terminaison de metadonnees cloud ou d'autres cibles non prevues.

API8 : Security Misconfiguration

Absence de durcissement de securite, politiques CORS permissives, messages d'erreur trop detailles, methodes HTTP inutiles activees, TLS manquant et points de terminaison de debug exposes. Couvre la couche d'infrastructure et de configuration entourant les API.

API9 : Improper Inventory Management

Les organisations qui perdent la trace des versions API deployees, des points de terminaison exposes et de la documentation accessible. Les anciennes versions API fonctionnant sans correctifs, les API fantomes et la documentation Swagger/OpenAPI exposee relevent toutes de cette categorie.

API10 : Unsafe Consumption of Third-Party APIs

Les API qui font confiance aux donnees recues de services tiers sans validation appropriee. Lorsqu'une application integre des API externes et traite leurs reponses sans assainissement ni verification, elle herite de la posture de securite de ces services externes.

Comment Utiliser le OWASP API Top 10

Pour les debutants, concentrez-vous d'abord sur API1 a API5. Ces cinq categories couvrent la majorite des constatations reelles en securite API et enseignent la mentalite fondamentale de test : verifier l'authentification, verifier l'autorisation, inspecter l'exposition de donnees et tester les limites de ressources.

Utilisez la liste comme une checklist lors des evaluations de securite API. Pour chaque point de terminaison, demandez-vous : le controle d'acces au niveau objet est-il applique ? L'authentification est-elle correctement imposee ? La reponse contient-elle des donnees excessives ? Les champs de requete peuvent-ils etre manipules ? Les fonctions sont-elles restreintes par role ?