Les risques de sécurité des API les plus importants

Quels sont les principaux risques de securite des API?

Les principaux risques de securite des API sont les categories de faiblesse que les attaquants exploitent le plus fiablement pour voler des donnees, detourner des comptes ou mettre un service hors ligne. Les applications modernes exposent la logique metier directement via des API, si bien qu'une seule verification d'autorisation defaillante peut exposer un jeu de donnees entier. Cette page enumere les risques les plus significatifs, alignes sur les categories reconnues du OWASP API Security Top 10, et explique pour chacun ce qu'il est, pourquoi il est dangereux et comment l'attenuer. Pour la discipline en general, voyez qu'est-ce que la securite des API, et pour les techniques d'attaque, voyez que sont les attaques d'API.

Risques d'autorisation

Les failles d'autorisation sont les risques d'API les plus dommageables car elles permettent a un utilisateur d'atteindre les donnees ou les fonctions privilegiees d'un autre. Les scanners automatiques les manquent car la requete elle-meme parait parfaitement valide.

Broken Object Level Authorization (BOLA)

Ce que c'est: l'API accepte un identifiant d'objet (par exemple /orders/1043) du client et renvoie l'enregistrement sans verifier que l'appelant en est proprietaire. Changer l'id renvoie les donnees d'un autre.

• Pourquoi c'est dangereux: BOLA est la faille grave la plus courante et se demultiplie facilement par simple enumeration des id.
• Comment l'attenuer: imposez une verification de propriete a chaque acces a un objet et limitez chaque requete a l'utilisateur ou a l'equipe authentifie. Preferez des identifiants aleatoires et non sequentiels.

Broken Function Level Authorization

Ce que c'est: l'API expose des operations privilegiees (une autre methode HTTP, une route /admin) sans verifier le role de l'appelant.

• Pourquoi c'est dangereux: un utilisateur ordinaire peut invoquer des fonctions reservees aux administrateurs, comme supprimer des enregistrements.
• Comment l'attenuer: refuser par defaut. Imposez les verifications de role dans un middleware central et ne comptez jamais sur le client pour masquer un bouton.

Broken Object Property Level Authorization

Ce que c'est: l'API renvoie ou accepte des proprietes que l'appelant ne devrait pas voir ou modifier. Elle fusionne l'exposition excessive de donnees (la reponse inclut des champs sensibles) et le mass assignment (l'API lie l'entree du client a des champs internes comme role sans allowlist).

• Pourquoi c'est dangereux: l'exposition excessive divulgue des donnees personnelles; le mass assignment permet d'elever ses privileges en ajoutant un champ au corps de la requete.
• Comment l'attenuer: ne renvoyez que les proprietes necessaires via des schemas de reponse explicites et liez les champs modifiables via une allowlist stricte.

Risques d'authentification

Broken Authentication

Ce que c'est: des faiblesses dans la verification d'identite, comme le credential stuffing sans limite de debit, une validation de token faible ou absente, des tokens qui n'expirent pas et des secrets dans les URL.

• Pourquoi c'est dangereux: une fois l'authentification contournee, tous les autres controles en aval sont sans effet; l'attaquant devient un utilisateur legitime.
• Comment l'attenuer: utilisez des bibliotheques eprouvees, validez la signature et l'expiration du token a chaque requete et appliquez le rate limiting sur les endpoints de connexion et de token.

Risques de ressources et de disponibilite

Unrestricted Resource Consumption

Ce que c'est: l'API ne limite pas les ressources qu'un appelant peut consommer: pas de rate limiting, pas de plafond de taille, pas de pagination et pas de limite sur les appels couteux vers des tiers.

• Pourquoi c'est dangereux: les attaquants peuvent provoquer un deni de service ou generer d'importantes factures d'infrastructure et de tiers.
• Comment l'attenuer: appliquez le rate limiting et des quotas par client, plafonnez la taille du corps et des tableaux et imposez la pagination. Ce controle doit etre teste sous charge reelle. Avec le load testing LoadFocus, vous envoyez un trafic controle et fortement concurrent vers un endpoint pour confirmer que les rate limits et l'autoscaling fonctionnent, et l'API monitoring LoadFocus surveille en continu la latence et les erreurs.

Unrestricted Access to Sensitive Business Flows

Ce que c'est: un flux metier (achat d'un article limite, creation de comptes) est expose sans protection contre l'usage automatise excessif, bien que chaque requete soit autorisee.

• Pourquoi c'est dangereux: l'automatisation peut accaparer un stock ou manipuler un systeme sans jamais briser un controle technique.
• Comment l'attenuer: identifiez les flux sensibles des la conception et ajoutez du device fingerprinting, des defis de verification humaine et une limitation propre au flux.

Risques serveur et de configuration

Server-Side Request Forgery (SSRF)

Ce que c'est: l'API recupere une ressource distante depuis une URL fournie par le client sans la valider, permettant au serveur d'interroger des systemes internes ou des endpoints de metadonnees cloud.

• Pourquoi c'est dangereux: le SSRF peut atteindre des services internes derriere le pare-feu et, dans le cloud, recolter des identifiants d'instance depuis le service de metadonnees.
• Comment l'attenuer: validez et mettez en allowlist les URL et schemas sortants, bloquez les plages d'adresses internes et desactivez les redirections HTTP sur les requetes serveur.

Security Misconfiguration

Ce que c'est: des valeurs par defaut peu sures, des messages d'erreur verbeux, des en-tetes de securite absents, un CORS trop permissif ou des fonctions de debogage actives en production.

• Pourquoi c'est dangereux: une mauvaise configuration livre aux attaquants des informations et des points d'appui sans aucun exploit sophistique.
• Comment l'attenuer: durcissez la configuration via un processus automatise et reproductible, desactivez les fonctions inutilisees et maintenez les dependances a jour.

Risques d'inventaire et de chaine d'approvisionnement

Improper Inventory Management

Ce que c'est: l'organisation ne connait pas toutes ses API. D'anciennes versions, des endpoints de staging exposes et des shadow API non documentees restent accessibles.

• Pourquoi c'est dangereux: un endpoint obsolete manque souvent des corrections de la version actuelle, offrant une porte non surveillee.
• Comment l'attenuer: tenez un inventaire vivant de chaque API, hote et version, et retirez les anciennes versions selon un calendrier.

Unsafe Consumption of APIs

Ce que c'est: l'API fait davantage confiance aux donnees d'API tierces ou en amont qu'aux donnees des utilisateurs, en omettant leur validation.

• Pourquoi c'est dangereux: un amont compromis peut injecter des charges qui affluent directement dans votre stockage car elles n'ont jamais ete verifiees.
• Comment l'attenuer: validez et assainissez les donnees tierces comme une entree utilisateur, utilisez des canaux chiffres et evaluez la posture de securite des partenaires.

Comment prioriser et attenuer ces risques

Corrigez d'abord l'autorisation, car BOLA et les failles de niveau fonction causent les plus grandes breches, puis progressez vers l'authentification, les limites de ressources et la configuration.

• Refuser par defaut: chaque acces a un objet et a une fonction commence non autorise jusqu'a une verification explicite.
• Valider tout ce qui franchit une frontiere de confiance: identifiants, champs du corps, reponses tierces et URL sortantes.
• Borner chaque endpoint: rate limits, quotas, plafonds de charge utile et pagination.
• Tenir un inventaire: connaissez chaque version et hote et retirez ce que vous ne prenez plus en charge.
• Tester et surveiller en continu: validez les defenses de consommation sous charge realiste et surveillez la production.

Risque	Cause typique	Attenuation
Broken Object Level Authorization (BOLA)	Aucune verification de propriete de l'id	Limiter chaque requete a l'utilisateur authentifie
Broken Function Level Authorization	Aucune verification de role	Refus par defaut centralise
Broken Object Property Level Authorization	Liaison d'objet complet, reponses non filtrees	Schemas explicites et allowlists d'ecriture
Broken Authentication	Gestion faible des tokens	Bibliotheques eprouvees et rate limits
Unrestricted Resource Consumption	Aucune limite ni plafond	Quotas, pagination, load testing
Unrestricted Access to Business Flows	Aucune anti-automatisation	Limitation et verification humaine
Server-Side Request Forgery (SSRF)	URL client non validees	Allowlists d'URL et plages internes bloquees
Security Misconfiguration	Valeurs par defaut peu sures	Configuration durcie et automatisee
Improper Inventory Management	Anciennes versions oubliees	Inventaire vivant et retrait des versions
Unsafe Consumption of APIs	Confiance aveugle en l'amont	Valider les donnees tierces comme l'entree utilisateur

FAQ sur les risques de securite des API

Quel est le risque de securite d'API le plus critique?

Broken Object Level Authorization (BOLA) est constamment classe le plus critique car il est courant, facile a exploiter en changeant un id d'objet et peut divulguer un jeu de donnees entier. Une verification de propriete par objet a chaque requete est la defense la plus rentable.

Comment ces risques se rapportent-ils a l'OWASP API Security Top 10?

Les risques de cette page correspondent directement aux categories de l'OWASP API Security Top 10, que la communaute de securite maintient comme liste de reference des faiblesses d'API les plus significatives et qui donne aux equipes un vocabulaire commun.

Quelle difference entre BOLA et broken function level authorization?

BOLA concerne les donnees: un utilisateur atteint les enregistrements d'un autre en changeant un identifiant. Broken function level authorization concerne les actions: un utilisateur invoque une operation, comme une fonction d'administrateur, que son role ne devrait pas permettre. Les deux naissent de verifications d'autorisation manquantes cote serveur.

Comment le load testing aide-t-il la securite des API?

Plusieurs risques, en particulier unrestricted resource consumption, se defendent par des rate limits, des quotas et l'autoscaling. Le load testing envoie un trafic controle et fortement concurrent pour confirmer que ces defenses se declenchent et tiennent sous stress. LoadFocus fournit du load testing dans le cloud et une surveillance continue des API pour cette validation.

Le rate limiting suffit-il a stopper l'abus d'API?

Le rate limiting est essentiel mais insuffisant. Il ralentit la force brute et le deni de service, mais n'arrete pas les failles d'autorisation, le SSRF ni l'abus de flux metier ou chaque requete est valide. Combinez-le a une autorisation stricte, a la validation des entrees et a des controles anti-automatisation.

A quelle frequence revoir nos risques de securite des API?

Traitez cela comme une demarche continue plutot que periodique. Revoyez l'autorisation et la validation a chaque nouvel endpoint, tenez un inventaire d'API a jour, corrigez rapidement les dependances et surveillez le trafic de production pour detecter tot les abus.