Tests de Sécurité des API : un Guide Complet

Vos contrôles existants prouvent probablement une seule chose bien : que le service se comporte correctement pour quiconque suit les règles. S’il repousse aussi ceux qui ne le font pas est une question différente, et une à laquelle la plupart des cycles de version n’atteignent jamais. Les tests de sécurité des API examinent si quelqu’un qui sait déjà comment parler à vos endpoints peut les faire mal se comporter.

Ils examinent comment vous gérez les connexions et les tokens, si chaque requête est autorisée à faire ce qu’elle demande, combien de trafic vous permettez, et ce que vos réponses révèlent. Ce travail a sa propre liste de risques, l’OWASP API Security Top 10. Ce n’est pas la même chose que la version générale des applications web que suivent la plupart des checklists.

Trois des dix risques API sont des défaillances d’autorisation, où le service sait exactement qui demande et remet quand même des enregistrements appartenant à quelqu’un d’autre. Une checklist d’application web regroupe tout cela dans une catégorie large. Nous recherchons ces défaillances pendant la QA quotidienne, et exécutons des services de tests d’intrusion quand une version nécessite une revue plus approfondie et ciblée.

Le reste de ce guide porte sur comment vérifier chacun d’eux.

En Quoi les Tests de Sécurité des API Diffèrent des Tests de Sécurité des Applications Web

Les tests de sécurité des applications web supposent une personne dans un navigateur. Quelqu’un remplit un formulaire, le soumet, et l’écran décide quoi lui montrer. Par conséquent, une grande partie de la protection vit sur cette page : des champs que vous ne pouvez pas modifier, des boutons que vous ne voyez jamais, des menus qui cachent tout ce que vous n’êtes pas censé atteindre.

Une API n’a rien de tout cela. Elle répond à quiconque envoie une requête correctement formée, et l’appelant est généralement un script plutôt qu’une personne. Alors, qu’est-ce que le test de sécurité des API en pratique ? C’est le travail de prouver que votre API refuse les requêtes qu’elle devrait refuser, même lorsqu’elles proviennent d’un compte qui s’est connecté avec succès.

C’est le changement qui prend les équipes par surprise. Les tests web classiques consacrent la majeure partie de leur effort à garder les étrangers dehors. En revanche, sur une API, vous partez de la prémisse opposée : l’appelant a déjà un token valide. La question intéressante n’est plus de savoir comment il y est arrivé mais jusqu’où il peut aller maintenant qu’il l’a.

Cela a deux conséquences pratiques :

• Votre logique métier se retrouve exposée plutôt qu’enveloppée dans une interface, donc une vérification côté front-end ne protège rien.
• Un script peut répéter une seule requête des milliers de fois par minute, ce qui transforme une petite négligence en une grande.

Les deux listes OWASP reflètent cette division. Côté application web, le contrôle d’accès défectueux est une seule entrée couvrant tout, d’une page admin cachée à un ID d’enregistrement altéré. La version API découpe le même terrain en trois risques distincts, car ces défaillances se présentent et se comportent différemment ici. Pour l’équivalent web, notre checklist de tests d’intrusion d’applications web le détaille, tandis que notre pratique de tests de sécurité couvre les deux surfaces.

Qu'est-ce que l'OWASP API Security Top 10 ?

L’OWASP API Security Top 10 est la référence pour ce travail, actuellement dans son édition 2023. Le test de sécurité des endpoints d’API a tendance à la suivre de près, car chaque élément nomme une défaillance que vous pouvez aller vérifier plutôt qu’un principe à garder à l’esprit.

Un point de terminologie mérite d’être clarifié d’abord. Si vous avez lu sur « l’exposition excessive de données » comme risque API, c’était le troisième élément de l’édition 2019. Il a été fusionné dans API3 lors de la révision 2023, donc l’ancien terme apparaît encore dans les articles et les outils tandis que la liste actuelle l’appelle autrement.

Les Trois Façons dont l'Autorisation API Échoue

Ces entrées décrivent la même erreur sous-jacente à différentes échelles. Ensemble, elles sont là où débutent la plupart des incidents API réels, et elles expliquent pourquoi ce profil de risque ne peut pas simplement hériter d’une checklist d’application web.

• API1, niveau objet. Votre API identifie l’appelant, puis échoue à demander s’il possède l’enregistrement particulier qu’il a demandé. Par exemple, une recherche pour la facture 1041 réussit, alors quelqu’un essaie 1042 et reçoit la facture d’un inconnu. La trouver n’a rien de glamour et c’est efficace : connectez-vous en tant qu’un client, collectez les identifiants que vous possédez légitimement, puis demandez ceux que vous n’avez pas et observez ce qui revient. Une API correcte répond par un refus. La vulnérable remet les données.
• API3, niveau propriété. Ici l’enregistrement vous appartient bien, mais l’échange porte plus qu’il ne devrait dans un sens ou dans l’autre. Un profil client pourrait renvoyer un score de risque interne ou un token de réinitialisation aux côtés du nom et de l’adresse, car l’endpoint envoie l’objet entier et fait confiance à l’app pour n’en afficher qu’une partie. L’inverse se produit aussi, où une mise à jour accepte un champ tel que role ou account_balance qu’aucun client ne devrait pouvoir définir. Les deux directions nécessitent des tests, car une réponse que l’app n’affiche jamais a quand même quitté votre serveur.
• API5, niveau fonction. Cette fois l’opération est hors limites plutôt que l’enregistrement. Un compte standard appelle la route d’un administrateur et ça fonctionne, car rien derrière ne revérifie qui demande. Sur un site web, un écran admin reste caché de la navigation et généralement oublié. Une API n’a pas de menu, donc chaque action privilégiée a besoin de sa propre protection, et chacune doit être testée depuis un compte ordinaire.

Remarquez ce que les trois ont en commun : rien n’a été forcé. Chaque requête était correctement formée, correctement authentifiée, et répondue exactement comme le code le prévoyait. C’est pourquoi elles survivent si confortablement aux tests fonctionnels, et pourquoi les attraper nécessite un cas qui demande délibérément quelque chose qu’il ne devrait pas recevoir.

Que Vérifier pour les Sept Risques Restants

Ceux-ci comptent toujours, bien que chacun nécessite moins de développement.

• API2, authentification. Regardez comment les tokens sont émis, combien de temps ils restent valides, si l’un fonctionne encore après déconnexion, et si un flux de réinitialisation de mot de passe peut être parcouru à l’envers.
• API4, consommation de ressources. Envoyez plus de trafic qu’aucun vrai client ne le ferait, des payloads surdimensionnés, et des requêtes que vous savez coûteuses. Vous voulez un refus clair plutôt qu’un effondrement lent.
• API6, flux métier. Demandez-vous ce qu’un concurrent ou un revendeur pourrait faire avec un accès automatisé illimité à une fonctionnalité qui fonctionne correctement. L’achat de billets et l’échange de bons sont les exemples habituels.
• API7, falsification de requête. Partout où votre API accepte une adresse web, pointez-la vers l’infrastructure interne et voyez si elle obéit.
• API8, configuration. Erreurs bavardes, en-têtes absents, et règles laissant n’importe quel site web appeler votre API vivent tous ici. Notre explication sur la configuration de sécurité erronée couvre le schéma plus en profondeur.
• API9, inventaire. Découvrez ce qui reste accessible. D’anciennes versions, des routes de staging, et des endpoints absents de la documentation sont courants, et ce que personne ne maintient n’est pas non plus corrigé.
• API10, consommation non sécurisée. Traitez les données arrivant de services externes avec la même suspicion que vous appliquez à l’entrée utilisateur, car une intégration de confiance peut quand même vous envoyer quelque chose de malformé.

Comment REST, GraphQL, gRPC, et SOAP Changent ce que Vous Testez

La liste OWASP est délibérément neutre vis-à-vis du protocole, ce qui aide pour la planification et se révèle insuffisant pour l’exécution. Les tests de sécurité des API doivent tenir compte de la façon dont votre service communique réellement, car le même risque surgit à un endroit différent selon la technologie sous-jacente.

REST et GraphQL

REST est là où l’autorisation au niveau objet échoue le plus souvent, pour des raisons structurelles plutôt que culturelles. Une adresse REST nomme la chose que vous demandez, donc l’identifiant se trouve juste là pour être modifié. Rien dans le style ne le rend moins sûr, mais cela rend une erreur particulière inhabituellement facile à commettre et simple à trouver. La version détaillée de cette vérification relève d’une checklist de sécurité spécifique à REST.

GraphQL déplace l’exposition ailleurs. Comme le client compose sa propre requête, une seule requête peut demander des données profondément imbriquées et coûteuses qu’aucune route REST ne permettrait. Cela transforme API4 en une décision de conception plutôt qu’un réglage de limite de débit. L’autre négligence fréquente est l’introspection : la fonctionnalité qui permet à n’importe quel client de demander à l’API de décrire sa propre structure. Laissée activée publiquement, elle remet à un visiteur une carte complète de votre modèle de données.

gRPC et SOAP

gRPC semble plus sûr par défaut, en grande partie parce qu’il n’y a pas d’outillage navigateur pratique et que les messages sont illisibles pour une personne. Cela joue contre vous pendant les tests plus qu’il n’aide en production. La réflexion de service, qui permet à un appelant de lister chaque méthode disponible, remet à un étranger une carte complète de votre service si vous la laissez activée. Les permissions doivent alors être vérifiées sur chacune plutôt que supposées à partir du transport.

SOAP arrive avec une spécification de sécurité intégrée, appelée WS-Security, et cela crée son propre piège. La configurer n’est pas la même chose que l’appliquer à chaque opération. Les analyseurs XML apportent aussi toute une famille de problèmes que les services construits sur JSON ne rencontrent jamais.

Pourquoi les Tests de Sécurité des API Relèvent-ils de la QA ?

L’erreur la plus courante que nous voyons est de traiter les tests de sécurité des API comme un projet ponctuel plutôt qu’un travail de routine. Ils sont planifiés une fois par an, gérés par des spécialistes externes, et rédigés des semaines après la version qu’ils décrivent.

Cet arrangement manque presque entièrement les défaillances d’autorisation, pour une raison simple. Les trouver dépend de la compréhension de ce que le produit est censé faire. Pourtant, un réviseur arrivant pour deux semaines n’a aucun moyen de savoir quels champs un client devrait voir, quelles routes sont réservées aux administrateurs, ou qui possède quel enregistrement. Vos ingénieurs QA savent tout cela, car ils ont écrit les tests fonctionnels qui codent ces règles.

La solution est une petite habitude à chaque version. Quiconque vérifie un endpoint demande aussi un enregistrement qu’il ne possède pas, et confirme le refus. Notre travail de tests d’API est construit ainsi, avec les cas de sécurité s’exécutant aux côtés des cas quotidiens plutôt que derrière eux.

Nous avons vu cela chez Union54, une API d’émission de cartes pour les fintechs africaines, testée sans aucune interface. Certains des défauts que nous avons signalés étaient des défaillances d’autorisation entre différents types d’utilisateurs. Rien de tout cela n’est sorti d’une revue de sécurité dédiée. Ces découvertes appartenaient plutôt à des ingénieurs QA qui connaissaient le produit assez bien pour remarquer quand la mauvaise personne recevait la bonne réponse.

Cela ne rend pas le travail spécialisé redondant. Un test d’intrusion ciblé mérite toujours sa place avant un lancement majeur, ou quand un régulateur ou un grand client en demande un. Cependant, il rapporte davantage une fois les lacunes évidentes fermées. Les spécialistes passent alors leur temps sur des problèmes que seuls eux peuvent trouver.

Comment Construire une Checklist de Tests de Sécurité des API

Savoir tester la sécurité des API s’avère moins une question de ce que la liste contient et davantage une question de qui la possède. Beaucoup d’équipes ont un document, mais presque personne ne l’ouvre pendant une version.

Organisez la vôtre autour des catégories OWASP plutôt que de vos endpoints. Un inventaire route par route devient obsolète la semaine après que vous l’ayez écrit, tandis que ces regroupements de risques restent stables à travers les versions et les technologies. Sous chacun, notez ce qui est vérifié, à quels chemins cela s’applique, et qui le valide.

Quatre décisions font plus pour une checklist que son contenu :

• Donnez-lui un seul propriétaire avec l’autorité de bloquer un lancement, jamais une boîte de réception partagée.
• Liez-la au processus de version que votre équipe suit déjà plutôt qu’à un calendrier de sécurité séparé.
• Rédigez chaque entrée comme une requête plus un refus attendu, afin que n’importe qui puisse l’exécuter et lire le résultat.
• Révisez-la chaque fois que vous ajoutez une route, changez un modèle de permission, ou intégrez une nouvelle intégration tierce.

Deux pièces adjacentes valent la peine d’être gardées ouvertes à côté :

• Notre checklist de test d’API REST couvre la moitié fiabilité, et le chevauchement est utile, car un cas de sécurité est souvent un cas fonctionnel avec le résultat attendu inversé.
• Notre travail sur les tests de performance d’API a aussi sa place ici, car tout ce qui limite l’abus vous porte également à travers un pic de trafic.

Un mot de prudence sur l’outillage. Les scanners font du bon travail sur la mauvaise configuration et la gestion des tokens, où les erreurs suivent des schémas reconnaissables. Ils sont presque inutiles sur les trois risques d’autorisation, car aucun outil ne peut savoir qui devrait posséder une facture donnée. Seule votre équipe a cette connaissance, donc le travail relève de l’assurance qualité plutôt que de l’extérieur.

Nous auditons les API par rapport à la liste OWASP à quelque étape que votre produit ait atteinte, que le build soit terminé ou que les endpoints soient encore en cours d’écriture. Pour découvrir ce que votre API remet à un appelant qui demande plus qu’il ne devrait, parlez à notre équipe QA.

Découvrez un échantillon de notre revue de code de sécurité d'une plateforme e-commerce basée aux États-Unis

Ce rapport met en avant les exploits que nous avons trouvés, catégorisés par gravité, avec des recommandations pour les corriger.

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir le PDF