La plupart des équipes traitent la sécurité des API comme un problème d’authentification. Elles ajoutent des jetons, les vérifient sur chaque route et considèrent le travail terminé. Puis un testeur change un seul chiffre dans une URL et lit la facture d’un autre client.

C’est dans cet écart entre « authentifié » et « autorisé » que se logent la plupart des vraies compromissions d’API, et un scanner ne les détecte pas de façon fiable. Un outil automatisé voit un jeton valide et une réponse 200, puis annonce un succès. Seul un humain qui comprend vos règles métier remarque que la réponse contenait les données de quelqu’un d’autre.

La distinction essentielle : l’authentification prouve qui appelle. L’autorisation décide de ce que cet appelant précis a le droit de voir ou de modifier, et elle doit être appliquée sur chaque objet, à chaque requête, dans la couche de données. Presque toutes les vulnérabilités d’API sérieuses sont une défaillance de la seconde alors que la première fonctionne parfaitement.

Autorisation d’objet défaillante, et pourquoi elle domine

La faille d’API grave la plus fréquente est aussi la plus simple à décrire.

Votre point de terminaison est /api/invoices/48213. L’appelant est authentifié, donc le gestionnaire récupère la facture 48213 et la renvoie. Personne ne vérifie que la facture 48213 appartient bien à cet appelant. Changez le numéro, obtenez la facture d’un autre. L’API s’est comportée exactement comme elle avait été écrite ; c’est l’écriture qui était fausse.

Cela passe mal à l’échelle pour vous et très bien pour un attaquant. Des identifiants séquentiels permettent d’énumérer l’intégralité de vos données avec une simple boucle. Passer à des identifiants impossibles à deviner aide un peu, mais ne corrige rien, car les identifiants fuient par d’autres points de terminaison, par les exports et par les e-mails.

Le correctif est structurel, pas accessoire. La propriété doit être vérifiée dans la requête elle-même : récupérer la facture qui appartient à ce client et porte cet identifiant, plutôt que récupérer la facture en espérant que quelque chose vérifiera plus tard. Placez cette règle dans la couche d’accès aux données, pour qu’elle ne puisse pas être oubliée dans un nouveau contrôleur écrit dans six mois par quelqu’un qui n’aura jamais lu ce paragraphe.

La même défaillance s’applique aux fonctions, pas seulement aux objets. Si un point de terminaison d’administration n’est protégé que par le fait que l’interface n’y renvoie pas les utilisateurs ordinaires, il n’est pas protégé du tout.

Les failles de sécurité des API qui reviennent vraiment

Au-delà de l’autorisation, une poignée de problèmes concentre l’essentiel des constats. L’OWASP API Security Top 10 est la référence en la matière, et l’OWASP la révise périodiquement : consultez l’édition en cours plutôt qu’un résumé.

Renvoyer plus que ce que l’interface affiche. Un point de terminaison renvoie l’objet utilisateur complet parce que c’était commode, et l’interface en affiche trois champs. Les douze autres, dont le jeton de réinitialisation du mot de passe et le score de risque interne, sont toujours dans la réponse. N’importe qui ouvrant l’onglet réseau les récupère. Sérialisez délibérément : construisez la réponse à partir de champs nommés au lieu de déverser un modèle entier.

L’affectation de masse à l’entrée. L’image miroir. Un point de terminaison de mise à jour de profil accepte tous les champs qui arrivent et les écrit dans l’enregistrement ; un appelant ajoute donc "role": "admin" et se promeut lui-même. Liez explicitement à une liste de champs autorisés au lieu d’accepter le corps de la requête en bloc.

Consommation sans limite. Sans plafond, un seul appelant peut demander un million d’enregistrements par page, lancer des recherches coûteuses en boucle ou déclencher des milliers de réinitialisations de mot de passe. Ce n’est pas seulement une question de déni de service ; lorsque chaque requête vous coûte de l’argent, comme avec un modèle de langage derrière votre point de terminaison, c’est une attaque sur votre facture. Les limites de débit se posent par consommateur et par point de terminaison, les opérations coûteuses étant bridées plus sévèrement que les autres.

Inventaire et confiance envers les tiers

Points de terminaison oubliés et non documentés. La version deux est en production et documentée, la version un tourne encore avec l’ancienne logique d’autorisation, et une API de préproduction contenant des données réelles est accessible depuis Internet. C’est exactement ce que cherchent les attaquants. Tenez un inventaire de chaque API déployée, de chaque version et de chaque environnement, et mettez hors service de façon délibérée plutôt que par négligence.

Faire confiance aux systèmes que vous appelez. Votre API consomme d’autres API, et leurs réponses atterrissent dans votre base de données et dans votre rendu. Validez ce qui revient au lieu de supposer qu’un partenaire est sûr. Une réponse venue de l’extérieur reste une entrée, avec tout ce que cela implique en matière de contrôle. Notre guide sur l’intégration d’API tierces traite le versant fiabilité de la même relation.

Réussir l’authentification

L’authentification est la partie que la plupart des équipes réussissent à peu près ; il s’agit donc ici des détails qui la ruinent.

Utilisez des jetons d’accès à durée de vie courte avec rafraîchissement, plutôt que des clés permanentes qui n’expirent jamais. Un identifiant fuité qui fonctionne indéfiniment est une compromission permanente ; un identifiant qui expire dans quinze minutes est un incident avec une fin bornée.

Restreignez la portée des jetons. Un jeton délivré à une intégration de reporting ne devrait pas pouvoir créer des utilisateurs. Les portées permettent d’imposer cela de façon centrale au lieu de compter sur la vigilance de chaque gestionnaire.

Validez les jetons correctement, ce qui revient surtout à ne pas accepter l’algorithme que le jeton déclare lui-même. Fixez l’algorithme de signature attendu, vérifiez l’émetteur et l’audience, et contrôlez l’expiration. Des bibliothèques le font par défaut ; c’est dans la vérification artisanale que se logent les erreurs.

Faites tourner les identifiants selon un calendrier et offrez à vos consommateurs un moyen de changer sans interruption, généralement en acceptant deux clés valides pendant la bascule. Si la rotation provoque une panne, personne ne la fera.

Enfin, ne mettez jamais d’identifiants dans les URL. Les chaînes de requête finissent dans les journaux serveur, l’historique du navigateur, les journaux de proxy et les en-têtes de référent. Utilisez les en-têtes.

Ce qu’un test d’intrusion trouve réellement

L’analyse automatisée et le test manuel trouvent des choses différentes, et vous avez besoin des deux pour des raisons différentes.

Les scanners sont bons sur les dépendances vulnérables connues, les en-têtes de sécurité manquants, les erreurs de configuration TLS et les injections évidentes. Faites-les tourner en continu dans votre chaîne d’intégration, parce qu’ils coûtent peu et rattrapent les régressions. Notre checklist d’audit de sécurité serveur détaille ce qui est contrôlé du côté de l’infrastructure.

Ce qu’ils ne savent pas faire, c’est raisonner sur votre métier. Un testeur découvre qu’un point de terminaison de code promotionnel peut être appelé plusieurs fois pour cumuler les remises, qu’une fonctionnalité payante reste accessible depuis une offre gratuite en appelant l’API directement, ou qu’annuler une commande déjà expédiée déclenche un remboursement sans contrôle de stock. Ce sont ces constats qui coûtent de l’argent réel, et ils n’apparaissent que si quelqu’un comprend à quoi sert votre API.

Pour une API en particulier, demandez que le test inclue des essais d’autorisation entre rôles : le testeur détient les identifiants de deux clients différents et tente systématiquement d’atteindre les données de l’un avec le jeton de l’autre. Cet exercice à lui seul trouve plus que tout le reste réuni. Notre panorama des types de tests d’intrusion explique quel niveau d’accès accorder, et fournir la documentation et des identifiants donne de bien meilleurs résultats qu’un test à l’aveugle.

Côté budget, un test centré sur une API va généralement d’environ £3,000 pour une petite API bien documentée à £15,000 ou plus pour une surface étendue comportant plusieurs rôles et intégrations. Notre guide du coût d’un test d’intrusion détaille ce qui fait varier cette fourchette.

Journaliser assez pour pouvoir enquêter

La différence entre un incident et une catastrophe tient généralement à votre capacité à reconstituer ce qui s’est passé.

Journalisez les événements d’authentification, les échecs d’autorisation et chaque opération qui modifie l’état, avec l’identité de l’appelant, l’objet visé et un identifiant de corrélation. Les échecs d’autorisation sont votre alerte précoce : une intégration légitime n’en produit presque aucun, donc une rafale signale quelqu’un qui sonde.

Ne journalisez pas les valeurs sensibles elles-mêmes. Des jetons, des données de carte ou des données personnelles dans des fichiers de log transforment une compromission contenue en compromission à déclarer.

Alertez sur les motifs plutôt que sur le volume. Un seul appelant qui génère des échecs d’autorisation sur de nombreux identifiants d’objets, c’est une énumération en cours, et cela mérite de réveiller quelqu’un. Le taux d’erreur global, non.

Conservez assez longtemps pour que ce soit utile. Les compromissions sont souvent découvertes des semaines après leur début, et trente jours de journaux suffisent rarement à retrouver le point d’entrée.

Testez l’API que vous avez réellement livrée

Mecanik propose des tests de sécurité applicative centrés sur les failles d’autorisation et de logique métier que l’outillage automatisé laisse passer, y compris des tests inter-comptes avec de vrais identifiants sur plusieurs rôles.

Nous travaillons à partir de votre spécification et de votre documentation plutôt qu’en devinant la surface exposée, ce qui met au jour, au passage, les points de terminaison non documentés et les versions oubliées. Lorsque le travail s’étend à l’infrastructure et au réseau, nos services de test d’intrusion couvrent ce terrain. Et si votre API se trouve derrière une application web, notre guide de l’audit de sécurité d’un site montre comment les deux examens s’articulent. Et si vous en êtes encore à concevoir l’API, notre guide du coût de développement d’une API indique où l’autorisation, la limitation de débit et la journalisation doivent se placer dans la construction plutôt que d’être ajoutées après coup.

Envoyez-nous la spécification et une description de vos rôles, et nous vous dirons où le risque se concentre.

Articles en relation: WordPress piraté : supprimer le logiciel malveillant , Conformité technique RGPD pour les développeurs britanniques , Cloudflare Zero Trust : guide de la sécurité d’accès pour l’entreprise , Tests d’intrusion UK - Ce qu’attendre en 2026 .

Questions fréquentes

Quelle est la vulnérabilité d’API la plus courante ? L’autorisation d’objet défaillante, où un appelant authentifié atteint les données d’un autre utilisateur en changeant un identifiant dans la requête. L’authentification fonctionne correctement, mais rien ne vérifie que l’objet demandé appartient à l’appelant. La propriété doit donc être imposée dans la requête elle-même.

Les clés d’API suffisent-elles à sécuriser une API ? Pas à elles seules. Des clés permanentes qui n’expirent jamais transforment la moindre fuite en compromission définitive. Utilisez des jetons d’accès à durée de vie courte avec rafraîchissement, limitez leur portée au strict nécessaire, permettez la rotation sans interruption et envoyez-les toujours dans les en-têtes plutôt que dans les URL.

Une analyse automatisée peut-elle sécuriser une API ? Non, même s’il vaut la peine d’en faire tourner en continu. Les scanners trouvent les dépendances vulnérables connues, les en-têtes manquants et les injections évidentes. Ils ne raisonnent pas sur vos règles métier, donc ils manquent les remises cumulées, les fonctionnalités payantes accessibles en offre gratuite et les accès inter-comptes.

Combien coûte un test d’intrusion d’API ? Généralement à partir d’environ £3,000 pour une petite API bien documentée et jusqu’à £15,000 ou plus pour une surface étendue avec plusieurs rôles et intégrations. Le coût dépend du nombre de points de terminaison, du nombre de rôles distincts et de la présence ou non d’une documentation et d’identifiants.

Que doit journaliser une API pour la sécurité ? Les événements d’authentification, les échecs d’autorisation et chaque opération qui modifie l’état, avec l’identité de l’appelant, l’objet visé et un identifiant de corrélation. Ne journalisez jamais de jetons ni de données personnelles. Alertez lorsqu’un même appelant produit des échecs d’autorisation sur de nombreux identifiants, signe d’une énumération.