API exposées
Les failles API les plus graves ne sont pas toujours les plus bruyantes. Authorization trop large, BOLA, secrets mal gérés, tokens persistants, endpoints de debug oubliés : un audit API doit tester ce qui est réellement exploitable et prioriser ce qui met vos clients et votre produit en risque.
L'audit API fait partie de l'offre Pentest expert : surface API cadrée sur devis après diagnostic.
Pentest web & API, audit IA, Toulouse, méthodologie OWASP/PTES
Livrables et priorisation
Expertise publique
Fondateurs Laucked
Les contenus clés sont reliés aux fondateurs, à des références anonymisées et à des surfaces de preuve consultables sans prise de contact.
Quand un audit API est utile
Explorateur d’endpoints
Pour chaque route, on contrôle l’auth, l’authorization, le scope, le rate-limit, l’exposition de données et le comportement face à des entrées malveillantes. Voici un extrait représentatif d’un audit Laucked, avec le type de finding qu’on remonte.
/v1/tenants/:id/objectsAPI1 · BOLA
severity HIGH
{
"error": "broken-object-level-authorization",
"tenant_observed": "tenant_a",
"tenant_token": "tenant_b",
"leak": "lecture autorisée"
}/v1/auth/loginAPI4 · Rate limiting
severity MED
{
"error": "no-rate-limit",
"endpoint": "/v1/auth/login",
"evidence": "1 200 attempts / 60 s sans verrou"
}/v1/payments/chargeAPI5 · BFLA
severity HIGH
{
"error": "broken-function-level-authorization",
"role": "support",
"operation": "charge",
"expected_role": "billing.write"
}/graphql · mutation updateUserAPI3 · Excessive data
severity MED
{
"error": "excessive-data-exposure",
"field": "user.tenantId",
"writable_by": ["tenant.admin", "support"]
}/v1/webhooks/inAPI8 · Misconfig
severity HIGH
{
"error": "missing-signature-validation",
"header": "X-Signature",
"consequence": "spoofing partenaire possible"
}Référentiel de couverture
L’audit suit le référentiel de référence pour la sécurité des API, complété par nos propres cas de test sur la logique métier. Pour chaque risque, voici ce que nous vérifions concrètement sur votre surface.
On tente d’accéder aux objets d’un autre tenant/utilisateur en manipulant les identifiants (path, query, body) avec un compte légitime.
Tokens faibles ou non expirés, JWT mal validés, reset de mot de passe contournable, absence de rotation, brute-force possible.
Excessive data exposure et mass assignment : champs sensibles lisibles ou modifiables (role, tenantId, is_admin) hors du périmètre attendu.
Absence de rate-limit sur les routes coûteuses ou critiques (login, export, recherche), pagination non bornée, coûts GraphQL non limités.
Accès à des fonctions d’administration ou financières depuis un rôle insuffisant (support qui déclenche un charge, user qui atteint /admin).
Abus de flux métier légitimes (création massive de comptes, réservation, achat) sans garde-fou anti-automatisation.
Paramètres d’URL fournis par l’utilisateur (webhooks, import distant) exploités pour atteindre le réseau interne ou les métadonnées cloud.
CORS trop permissif, signatures webhook non vérifiées, entêtes de sécurité absents, verbes HTTP non restreints, endpoints de debug exposés.
Versions d’API obsolètes (v1 laissée ouverte), endpoints fantômes, environnements de test accessibles depuis Internet, documentation qui fuite des routes.
Confiance excessive envers les API tierces consommées : données non validées, redirections suivies, secrets partenaires trop larges.
Référentiel : OWASP API Security Top 10 · 2023 (owasp.org).
Cas client anonymisé
Le produit exposait une API REST consommée par des partenaires, un espace client multi-tenant et des endpoints internes trop largement accessibles depuis Internet.
Corrections priorisées en 8 jours. La synthèse dirigeant a servi directement dans le questionnaire sécurité du client final.
{
"remediation": "priorisée par sévérité",
"lead_time_days": 8,
"reuse": ["questionnaire client", "revue fournisseur"]
}Questions fréquentes
Un audit API va plus loin sur les contrôles d'accès, le cloisonnement inter-tenant, les scopes, les tokens et les intégrations. C'est souvent la zone la plus sensible d'un SaaS B2B.
Oui. GraphQL a ses propres angles : introspection laissée ouverte, absence de limite de profondeur ou de complexité (déni de service par requête imbriquée), autorisation par résolveur, mutations non scopées. On teste REST, GraphQL et webhooks avec la même exigence de logique métier.
On utilise au moins deux comptes de tenants distincts et on tente systématiquement d'accéder, lire ou modifier les objets de l'un depuis l'autre (BOLA/API1), sur chaque route qui porte un identifiant. C'est le défaut le plus fréquent et le plus grave sur un SaaS B2B, et un scanner ne le voit pas car les deux réponses sont des 200 valides.
Non. Le scan peut aider à cartographier, mais l'audit API utile repose sur des tests manuels, de la logique métier et la vérification d'exploitabilité. Chaque finding est validé avec une preuve reproductible, pas remonté sur signature.
Celles qui exposent des données client, de l'authentification, de l'administration, des flux partenaires ou de la facturation. Plus la logique métier est critique, plus la vérification doit être précise.
C'est un plus mais pas un prérequis. Une spec OpenAPI accélère le cadrage et la couverture. À défaut, on cartographie la surface à partir du trafic réel, du front qui consomme l'API et d'une session de découverte avec votre équipe.
Un audit API utile doit aider à corriger, mais aussi à documenter. Si vos clients, vos partenaires ou vos dirigeants veulent une vue défendable du risque, le travail doit être lisible autant qu’offensif.