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.
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.