Une API est protégée par une passerelle. Les utilisateurs possèdent des jetons valides et les connexions passent par HTTPS. Pourtant, un employé pourrait consulter le dossier d’un autre client. Comment est-ce possible malgré ces protections ?
Imaginons un portail client fictif. Un employé peut voir le dossier 481, remplace son identifiant par 482 dans une requête et obtient des données appartenant à une autre organisation. Le jeton est valide, la passerelle transmet la requête, mais l’application ne contrôle pas si cet utilisateur peut consulter précisément ce dossier.
Ce que le NIST a actualisé en 2026
Le National Institute of Standards and Technology a publié SP 800-228, Guidelines for API Protection for Cloud-Native Systems, en juin 2025. Le 13 mars 2026, deux annexes ont été ajoutées sur les catégories de risques liés aux API et les mesures recommandées au cours de leur cycle de vie. Cette approche fondée sur les risques n’impose pas un produit ou fournisseur de passerelle particulier.
Un jeton valide n’autorise pas le dossier 482
Une passerelle peut acheminer le trafic, protéger les connexions et appliquer des limites communes. Le fournisseur d’identité gère les comptes et les jetons. Mais aucun des deux ne connaît automatiquement les droits sur chaque dossier. L’OWASP décrit la Broken Object Level Authorization (BOLA) : l’accès à un endpoint n’implique pas le droit de consulter tous les objets identifiables.
Dans un système multi-tenant, l’application doit vérifier à quelle organisation appartient l’objet, d’où vient ce contexte et si l’appelant peut le modifier. Un identifiant d’organisation issu d’un paramètre non fiable ne suffit pas à prouver un droit. Masquer un élément dans le frontend n’est pas un contrôle d’autorisation côté serveur.
Un endpoint protégé ne prouve pas que tous le sont
Même si la lecture d’un dossier est correctement contrôlée, les recherches, listes, exports massifs ou anciennes versions de l’API peuvent révéler les mêmes données. Les messages d’erreur trop détaillés peuvent également divulguer des informations. Chaque parcours pertinent doit appliquer les droits d’accès.
Les règles métier ont leur propre rôle
Un employé peut lire un dossier sans pouvoir le rouvrir lorsqu’il est clôturé. Une demande de paiement répétée peut nécessiter une gestion idempotente et transactionnelle. Il ne s’agit pas exactement du même problème que BOLA, mais d’une autre raison de distinguer authentification, autorisation et règles métier. Une limitation de débit ne remplace pas ces contrôles.
Tester surtout ce qui doit être refusé
Dans un environnement de test, créez deux utilisateurs de deux organisations différentes. Avec le jeton du premier, essayez de lire, modifier et exporter un dossier du second. Vérifiez le refus, l’absence de fuite dans les journaux et l’absence de modification en base. Répétez avec des jetons expirés, des droits révoqués, des recherches et des demandes dupliquées. Précisez quel composant doit appliquer chaque règle.
Plus de couches ne garantit pas plus de sécurité
Une passerelle supplémentaire peut uniformiser certains contrôles, mais ajoute configuration et maintenance. Une API interne simple n’a pas le même modèle de risque qu’une plateforme publique multi-tenant. Documentez les responsabilités, les tests, la rotation des identifiants et la surveillance des incidents sans conserver inutilement des secrets ou données personnelles.
La sécurité apparaît lorsqu’une requête valide est refusée
Le test décisif n’est pas qu’un jeton passe la passerelle, mais qu’une action interdite soit réellement bloquée. La sécurité repose sur des responsabilités vérifiables plutôt que sur le nombre de produits installés.
maintenance et dette technique.
Sources
Contactez-nous
Dites-nous comment nous pouvons vous aider ; nous répondons sous deux jours ouvrés.
