Audit de sécurité d'API, chaque accès vérifié.
Un audit de sécurité d'API, ou pentest d'API, vérifie que chaque endpoint REST, JSON ou GraphQL n'expose que ce qu'il doit, et seulement à qui de droit. Nos outils maison rejouent chaque route avec chaque rôle, et notre expertise manuelle repère les réponses qui n'auraient jamais dû passer. Sur une API, une grande partie des failles graves se cachent dans l'autorisation.
En bref
- Le périmètreVos endpoints REST, JSON et GraphQL, avec leur authentification et leurs webhooks.
- Ce que nous cherchonsDes objets accessibles à des comptes qui ne devraient pas y toucher, des champs qu'on peut forcer, des réponses qui en disent trop.
- Ce qu'il nous fautDeux comptes de même niveau, puis un par rôle. Votre spécification OpenAPI ou votre schéma GraphQL, si vous en avez un.
- Ce que vous recevezUn rapport avec la matrice d'autorisation et la preuve de chaque faille, une restitution avec votre équipe et un retest sous 60 jours.
Vulnérabilités trouvées dans ces secteurs
- Services publics (.gouv.fr)
- Groupes du CAC 40
- Leaders du luxe
- Médias nationaux
- Mairies et collectivités
Votre application envoie « client ». Un attaquant envoie « admin ».
Et il ne s'arrête pas aux routes de votre site : anciennes versions, routes internes, endpoints oubliés, tout ce qui répond encore. Si votre API accepte un seul mot de trop, un compte gratuit devient administrateur.
Votre application n'envoie que les champs prévus et n'appelle que les routes dont elle a besoin. Un attaquant lit ces requêtes, puis les réécrit : un champ « role » ajouté à une inscription, l'identifiant d'un autre client, une route d'administration appelée avec un jeton ordinaire.
Aucune de ces failles ne demande d'outil sophistiqué, et aucune ne laisse d'erreur dans vos journaux : du point de vue du serveur, tout s'est bien passé. Ce sont pourtant parmi les plus graves que nous trouvons sur des API.
C'est aussi pourquoi un scan de vulnérabilités ne remplace pas un test d'intrusion : aucune signature ne sait qui a le droit de lire quoi.
Avant le correctif
Un jeton de client ouvre la liste de tous les comptes : la route ne vérifie pas le rôle de l'appelant.
Après le correctif
La route vérifie le rôle à chaque appel : un jeton de client reçoit un refus.
Le même jeton, une route d'administration. Retournez la carte pour voir la correction.
Quand auditer votre API.
Une API change plus vite que les applications qui la consomment : chaque nouvelle route, chaque nouvelle intégration, chaque nouvelle version est une surface à vérifier.
Avant de l'ouvrir à des partenaires
Dès qu'un tiers reçoit une clé, chaque route devient une porte qu'il peut appeler comme il l'entend.
À la sortie d'une application mobile
Une application se décompile en quelques minutes : les routes qu'elle appelle, et celles qu'elle n'appelle plus, deviennent publiques.
Avant une nouvelle version
Une v2 apporte ses routes, et la v1 reste souvent en ligne, avec ses anciens contrôles.
Une fois par an
Vos référentiels et vos clients attendent un test régulier, et vos routes changent à chaque sprint.
Après un incident ou une alerte
Comprendre quelle route a parlé, et vérifier que ses voisines ne disent pas la même chose.
Ce que nous testons.
Six familles de failles d'API, cherchées à chaque audit, et la route où chacune se cache.
Autorisation par objet
Atteindre l'objet d'un autre compte, une commande ou un dossier, en changeant son identifiant dans une requête légitime. : lire ou modifier les données d'un autre compte en changeant un identifiant.
Autorisation par fonction
Appeler une fonction réservée, comme une route d'administration, avec un compte qui n'y a pas droit. : export, suppression ou gestion des rôles appelés avec un compte standard.
Champs forcés et données exposées
Glisser dans le corps d'une requête un champ que l'API n'aurait pas dû accepter, comme un rôle ou un statut de paiement., et des réponses qui renvoient l'objet complet quand l'écran n'en montre que trois champs.
Authentification et jetons
Signature et algorithme des Le jeton signé qui porte l'identité de l'appelant. Une signature mal vérifiée suffit à le falsifier., expiration, révocation, rafraîchissement, OAuth et OIDC, clés d'API.
GraphQL
La requête qui demande à une API GraphQL de décrire tout son schéma : une carte complète pour un attaquant si elle reste ouverte. ouverte, requêtes imbriquées coûteuses, contrôles posés sur la requête racine au lieu des résolveurs, alias pour contourner les limites.
Injections, débit et intégrations
SQL et NoSQL dans les filtres, Pousser votre serveur à appeler une adresse choisie par l'attaquant, souvent votre réseau interne. sur les appels sortants, webhooks non signés ou rejouables, routes sans limite de débit, anciennes versions encore en ligne.
Comment se déroule un audit d'API.
Six étapes, du cadrage au retest, construites autour de la matrice d'autorisation.
Lire la méthodologie complète- 01
Cadrage et accès
On liste les API concernées, les environnements et les rôles à couvrir. Idéalement, vous fournissez une spécification OpenAPI ou un schéma GraphQL, et des comptes distincts : au moins deux du même niveau, pour l'accès horizontal, puis un par niveau de privilège. NDA dès que l'on entre dans le détail technique, convention d'autorisation de test d'intrusion une fois le devis signé, avant tout accès.
- 02
Cartographie des routes
Inventaire complet des endpoints, des méthodes acceptées, des paramètres et des formats de réponse. Cette étape révèle régulièrement des routes oubliées : anciennes versions encore en ligne, endpoints internes joignables de l'extérieur, routes de débogage restées actives.
- 03
Matrice d'autorisation
Le cœur de l'audit. Pour chaque route sensible, nous rejouons la même requête avec chaque rôle, et avec les identifiants d'objets d'autres comptes. Nos outils maison déroulent la matrice, et nous lisons chaque réponse qui n'aurait pas dû passer.
- 04
Manipulation des données
Champs ajoutés dans les corps de requête, types modifiés, valeurs limites, structures imbriquées inattendues. Nous cherchons ce que le serveur accepte alors qu'il ne devrait pas, jusqu'à un impact démontré.
- 05
Rapport et restitution
Un rapport classé par gravité réelle, avec pour chaque faille la requête exacte qui la démontre, ce qu'un attaquant en tirerait et la correction à apporter. Puis une restitution avec votre équipe. Voir un exemple de rapport.
- 06
Retest & clôture
Une fois vos correctifs déployés, nous rejouons chaque requête en cause, avec chaque rôle concerné. Une route corrigée pour un rôle et oubliée pour un autre reste ouverte : le retest est inclus pour s'en assurer.
Boîte noire, grise ou blanche.
Ce que vous nous donnez au départ décide de ce que l'audit peut atteindre. Pour une API, notre conseil : un jeton par rôle et votre spécification.
Boîte noire : l'adresse, rien d'autre
- Vous fournissez
- L'adresse de l'API, ou l'application qui la consomme. Aucun compte, aucune documentation.
- Le test atteint
- Les routes publiques, et celles qu'on retrouve en observant le trafic de vos applications. L'authentification arrête le reste, sauf faille pour la franchir.
- À choisir quand
- Vous voulez savoir ce qu'un inconnu tire de votre API depuis Internet. La cartographie prend alors une bonne part du temps.
Boîte grise : un jeton par rôle Notre conseil
- Vous fournissez
- Deux comptes de même niveau, puis un par rôle, et votre spécification OpenAPI ou votre schéma GraphQL si vous en avez un.
- Le test atteint
- Chaque route avec chaque rôle, y compris celles qu'aucune application n'appelle encore : la matrice d'autorisation complète.
- À choisir quand
- Dans presque tous les cas. C'est elle qui trouve les failles d'autorisation, fréquentes et souvent graves sur une API.
Boîte blanche : les jetons et le code
- Vous fournissez
- Les comptes et la spécification, plus un accès au code des contrôleurs et des résolveurs.
- Le test atteint
- Aussi les chemins que la documentation ne décrit pas, et la logique d'autorisation telle qu'elle est écrite.
- À choisir quand
- Sur une API critique et spécifique, quand la profondeur compte plus que le réalisme.
Ce que ça donne en pratique.
Des failles réelles trouvées sur des API, toutes corrigées depuis.
rapports envoyés avec une vulnérabilité critique
Sur plus de 485 rapports envoyés, en test d'intrusion et en bug bounty.
rapports envoyés au total
En test d'intrusion et en bug bounty.
Actifs en bug bounty
Chercheurs sur YesWeHack et Intigriti, deux plateformes européennes où chaque faille est vérifiée avant d'être acceptée.
- CritiqueCorrigée
BOLA
Lecture des données de n'importe quel client en incrémentant un identifiant dans une requête légitime.
- CritiqueCorrigée
Mass assignment
Passage d'un compte standard en administrateur par un champ non filtré à l'inscription.
- ÉlevéeCorrigée
Exposition de données
Une réponse d'API renvoyant des champs personnels que l'interface n'affichait pas.
- ÉlevéeCorrigée
GraphQL
Un contrôle d'accès posé sur la requête racine mais absent des résolveurs imbriqués, contourné par une relation.
- ÉlevéeCorrigée
Contournement de facturation
L'usage complet d'une API payante sans jamais déclencher le paiement.
Nous ne divulguons jamais le nom d'un client, ni aucun détail qui permettrait de le reconnaître.
Le rapport que vous recevez.
Chaque faille avec la requête qui la prouve, ce qu'elle expose et la façon de la corriger : lisible par votre direction, utilisable par vos développeurs.
Les données de n'importe quel client, lisibles en incrémentant un identifiant dans une requête par ailleurs légitime. Toute la base clients exposée, sans une seule erreur dans les journaux.
GravitéCritique, un identifiant incrémenté
Requêtes, réponses et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Vérifier côté serveur, pour chaque route et chaque objet demandé, qu'il appartient bien au compte qui appelle, et refuser par défaut.
PrioritéImmédiate, retest inclus
Un compte standard promu administrateur en ajoutant un seul champ à la requête d'inscription : l'accès complet à la plateforme.
GravitéCritique, un champ ajouté
Requêtes, réponses et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
N'accepter, pour chaque route, que les champs prévus, et ne jamais lier un corps de requête directement au modèle de données.
PrioritéImmédiate, retest inclus
Le contrôle d'accès posé sur la requête racine manquait aux résolveurs imbriqués : des objets d'autres comptes, atteints en passant par une relation.
GravitéÉlevée, par une relation
Requêtes, réponses et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Poser le contrôle d'autorisation dans chaque résolveur, au niveau de l'objet renvoyé, et non sur la seule requête d'entrée.
PrioritéHaute, retest inclus
Matrice d'autorisation
Chaque route sensible croisée avec chaque rôle : ce qui doit répondre, ce qui doit refuser, et ce qui répond à tort.
Requêtes rejouables
Chaque faille avec la requête exacte, prête à rejouer dans votre client HTTP ou votre suite de tests.
Impact métier
Quelles données, quels comptes, quelles opérations sont exposés, dit en clair pour votre direction.
Remédiation précise
La correction à appliquer sur chaque route ou chaque résolveur en cause, pour l'équipe qui maintient l'API.
Retest inclus
Une fois vos correctifs en ligne, chaque requête est rejouée avec chaque rôle : la faille n'est close que lorsqu'elle ne passe plus.
Restitution & échange
Un échange avec vos développeurs pour parcourir les routes en cause, répondre à leurs questions et prioriser les corrections.
Combien ça coûte.
Sur devis, et voici pourquoi : la taille réelle d'une API ne se voit qu'au cadrage. Pour vous situer, voici nos tarifs selon le type de mission.
À partir de3 200 € TTC
API ciblée
Quatre à huit jours. Une API REST ou GraphQL, ses rôles et ses routes sensibles, webhooks compris.
À partir de7 500 € TTC
Application métier ou SaaS
Dix à quinze jours ou plus. L'API et les applications qui la consomment, avec des rôles et des droits qui se croisent.
À partir de2 700 € TTC
Site vitrine ou boutique
Quatre à six jours. Le site public et l'API légère qui le sert : formulaires, espace client, panier.
Ce qui fait varier le prix
Sur une API, deux chiffres dominent tout le reste. Le nombre de routes sensibles, d'abord : pas le total des routes, mais celles qui manipulent des données ou des droits. Puis le nombre de rôles. Ils se multiplient : la matrice d'autorisation à vérifier est le produit des deux.
S'ajoutent GraphQL, qui demande une approche propre, et les webhooks entrants ou les intégrations tierces, qui ajoutent chacun une surface. Une Le fichier qui décrit toutes les routes de votre API, leurs paramètres et leurs réponses. à jour réduit nettement le temps de cartographie, donc le devis.
Le premier échange sert à poser ces deux chiffres, sans engagement. Si votre API est plus simple que prévu, nous vous le dirons.
25requêtes à rejouer
Doit répondreDoit refuser
Chaque case est une requête. La même route, rejouée avec chaque rôle : elle doit répondre, ou refuser. Cinq routes et deux rôles font dix requêtes, cinq rôles en font vingt-cinq. Sur une vraie API, ce produit se compte en centaines, et c'est lui qui fait la durée de l'audit.
Une preuve pour vos audits.
Les référentiels qui demandent de tester vos mesures de sécurité couvrent aussi vos API. Notre rapport est une pièce que vos auditeurs savent lire : routes testées, méthode, preuves et corrections vérifiées.
ISO/IEC 27001
Annexe A, mesures 8.8 et 8.29
Les API entrent dans le périmètre des tests de sécurité. Le rapport montre quelles routes ont été testées, ce qui a été trouvé, puis corrigé.
PCI DSS
Exigence 11.4
Une API qui touche au paiement est dans le périmètre des tests d'intrusion. Le retest inclus documente chaque correction.
SOC 2
Critère CC4.1
Un test récent de votre API, souvent demandé comme évaluation indépendante de vos contrôles d'accès.
RGPD
Article 32
Une API qui sert des données personnelles doit être testée régulièrement. Le rapport en est une trace datée.
NIS 2
Article 21
Évaluer l'efficacité de vos mesures de sécurité, y compris sur les interfaces ouvertes à vos partenaires.
DORA
Articles 24 et 25
Pour les entités financières, des tests de résilience numérique qui couvrent aussi les API ouvertes aux tiers.
Nous ne délivrons pas de certification : nous fournissons la preuve technique que vos auditeurs demandent. Notre méthode couvre l'API Security Top 10 de l'Fondation à but non lucratif qui publie les référentiels de sécurité les plus utilisés, dont l'API Security Top 10, la liste des risques d'API que nous couvrons. et suit la structure du Penetration Testing Execution Standard : la trame d'une mission de test d'intrusion, du cadrage au rapport., détaillée ici.
Faut-il fournir la documentation de l'API ?
Ce n'est pas obligatoire, mais une spécification OpenAPI ou un schéma GraphQL accélère beaucoup la couverture et permet de tester des routes qu'aucune application n'appelle encore. À défaut, nous cartographions l'API en observant le trafic réel de vos applications clientes.
Mon API est protégée par une clé, est-ce suffisant ?
Non. Une clé répond à la question « qui appelle », jamais à la question « a-t-il le droit d'accéder à cet objet précis ». Une grande partie des failles graves que nous trouvons sur des API concernent l'autorisation par objet, pas l'authentification.
GraphQL est-il plus risqué que REST ?
Pas intrinsèquement, mais il déplace le risque. L'introspection expose souvent tout le schéma, les requêtes imbriquées permettent d'atteindre des objets par des chemins auxquels personne n'avait pensé, et une seule requête profonde peut coûter très cher au serveur. Les contrôles doivent être posés au niveau du résolveur, pas de la route.
Testez-vous aussi les webhooks et les intégrations tierces ?
Oui, quand ils sont dans le périmètre. Les webhooks entrants sont un point d'entrée souvent oublié : signature non vérifiée, rejeu possible, ou traitement qui fait confiance au contenu reçu. OAuth et OIDC sont également couverts.
Peut-on auditer une API en production ?
Oui, c'est le cas le plus fréquent. Les tests destructifs et les tests de charge sont exclus par défaut. Sur les routes d'écriture, nous travaillons sur des ressources créées pour l'occasion plutôt que sur vos données réelles.
Combien de temps dure un audit d'API ?
De quatre jours pour une API ciblée à plusieurs semaines pour une plateforme aux nombreux rôles. La durée suit le nombre de routes sensibles multiplié par le nombre de rôles. Elle est fixée au cadrage, avant signature.
Testez-vous l'API d'une application mobile ?
Oui, l'API elle-même : c'est souvent la plus exposée, parce que n'importe qui peut observer ou décompiler l'application et rejouer ses appels. Le test de l'application native, son stockage local ou son binaire, n'est pas notre spécialité : nous vous orienterons vers un spécialiste de confiance.
Les autres prestations.
Votre API n'est qu'une partie de ce que vous exposez ? Une autre mission peut la compléter.
Test d'intrusion web
L'application qui consomme l'API, ses rôles et ses parcours, testés comme le ferait un attaquant.
Voir la prestationAudit de sécurité WordPress
WordPress expose sa propre API REST, souvent ouverte par défaut.
Voir la prestationAudit de sécurité de site web
Site vitrine, boutique ou CMS : la sécurité de ce que vos visiteurs voient.
Voir la prestationAuthentification et permissions
Connexion, sessions, SSO et rôles : qui peut entrer, et jusqu'où.
Voir la prestationFaites auditer votre API.
Votre API est une cible.
Dites-nous combien de routes sensibles et de rôles vous avez, et si vous disposez d'une spécification OpenAPI ou d'un schéma GraphQL. Nous répondons avec un cadrage et un devis. Premier échange sans engagement.