Ce qu'un scan voit, et ce qu'il ne voit pas
Les outils repèrent bien des CVE, des headers manquants ou certaines erreurs de configuration. C'est utile, mais cela ne dit pas si un compte peut lire les objets d'un autre tenant, si un webhook est vraiment digne de confiance ou si un rôle support a trop de pouvoir.
Dès qu'une API porte des rôles, des objets métier, des comptes partenaires ou un portail client, le risque principal devient logique. C'est là que le test manuel devient décisif.
Les contrôles qui comptent le plus
Auth et gestion des tokens
Le test vérifie comment les utilisateurs et les services s'authentifient, comment les tokens expirent, se renouvellent ou circulent.
Authorization et objets exposés
Le cœur d'un pentest API est souvent là : est-ce qu'un utilisateur peut agir sur un objet qui ne lui appartient pas ?
Logique métier et intégrations
Webhooks, rôles, changements d'état, flux partenaires. Beaucoup de failles n'apparaissent qu'en reconstituant le vrai usage métier.
Exemple de matrice de test des autorisations
Ce scénario est fictif : deux clients A et B disposent de factures de test. Pour chaque compte, on vérifie une opération autorisée puis la même opération sur un objet ou une fonction qui devrait être refusé. Les droits attendus sont validés avec votre équipe avant la mission.
| Compte | Objet et opération | Résultat attendu | Preuve |
|---|---|---|---|
| Lecteur du tenant A | Lire une facture de A | Lecture autorisée | Requête et résultat sur données fictives |
| Lecteur du tenant A | Lire une facture de B | Accès refusé sans fuite de données | Réponse et absence de données de B |
| Lecteur du tenant A | Modifier une facture de A | Modification refusée | Réponse et état de la facture inchangé |
| Support à droits limités | Exporter les données hors de son périmètre | Export refusé selon les droits convenus | Contrôle du fichier et de la traçabilité |
| Jeton révoqué | Réutiliser un accès à une ressource protégée | Accès refusé après le délai de révocation prévu | Horodatage de révocation et résultat du test |
Une simple réponse HTTP ne suffit pas : le test contrôle aussi l'état de l'objet, les données retournées et les effets secondaires. La matrice précise les parcours testés ; elle ne garantit pas la couverture de tous les endpoints.
Ce qu'il faut préparer pour cadrer le pentest API
- La liste des environnements autorisés, des versions d'API et des endpoints exposés.
- Une documentation OpenAPI ou une collection de requêtes, si disponible.
- Des comptes pour les rôles convenus, deux tenants fictifs et des objets de test.
- Les règles métier attendues : droits, limites d'usage, changements d'état et révocation.
- Les intégrations et webhooks autorisés au test, avec leurs exclusions.
- Un interlocuteur, les créneaux, les conditions d'arrêt et les documents attendus.
Le choix entre boîte noire, grise ou blanche dépend des accès disponibles et de l'objectif. Pour comparer les offres, utilisez les éléments de cadrage d'un devis pentest.
Les livrables à attendre du test
Demandez un périmètre explicite, les comptes et scénarios couverts, les limites de test, les preuves reproductibles et les recommandations. Le rapport distingue la sévérité technique de la priorité métier. Les conditions du contre-test précisent quels constats seront revérifiés et dans quelle fenêtre.
Le rapport d'exemple fictif illustre la restitution. Le guide OWASP API Top 10 décrit les familles de risques et leurs contrôles ; cet article sert au cadrage de votre mission.
Les failles API qui coûtent vraiment
Dans la pratique, on voit surtout des accès inter-tenant, des scopes trop larges, des endpoints « internes » exposés depuis le front, des webhooks insuffisamment authentifiés ou des actions sensibles déclenchables sans contrôle suffisant.
Le cas classique reste le BOLA : un identifiant est valide, mais l'API ne vérifie pas assez finement que l'objet demandé appartient bien au bon compte, au bon tenant ou au bon rôle. Voir notre article dédié IDOR/BOLA.
Quand demander un audit API ciblé
Le bon moment n'est pas seulement « quand il y a une API ». C'est quand cette API devient une surface de confiance pour un client, un partenaire, un portail exposé ou une intégration critique.
Dans ce cas, un audit dédié permet de produire un périmètre net, des constats exploitables et une remédiation priorisée sur ce qui expose réellement la donnée et la logique métier. Voir la page service audit API.
Pour approfondir : OWASP : contrôles de sécurité des services REST.