Audit de sécurité d'API, là où vivent vos données.
Un audit de sécurité d'API vérifie que chaque endpoint REST, JSON ou GraphQL n'expose que ce qu'il doit, et seulement à qui de droit. Sans interface pour masquer quoi que ce soit, une API applique exactement les règles qu'on lui a écrites. Tout l'enjeu est de savoir si elles ont vraiment été écrites.
Le contrôle d'accès n'est pas dans le bouton.
Dans une application classique, l'interface guide l'utilisateur. Elle masque les actions interdites, elle grise les boutons, elle n'affiche pas les champs réservés aux administrateurs. Beaucoup d'équipes en déduisent, sans jamais le formuler, que l'utilisateur ne peut faire que ce que l'interface propose.
Une API n'a pas d'interface. Elle a des routes, et n'importe qui peut les appeler directement, avec les paramètres de son choix, et dans l'ordre de son choix. Si la vérification « cet utilisateur a-t-il le droit de lire cet objet précis ? » n'a pas été écrite côté serveur pour chaque route, elle n'existe pas.
C'est la faille la plus courante et la plus grave que je trouve sur des API. Elle ne demande aucun outil sophistiqué : il suffit de changer un identifiant dans une requête légitime. Elle ne produit aucune erreur dans vos logs, parce que du point de vue du serveur, tout s'est bien passé.
Ce que je teste.
REST, JSON, GraphQL, webhooks, OAuth et OIDC, WebSockets. Voici les familles de problèmes couvertes systématiquement.
- Autorisation par objet (BOLA, IDOR) : accéder aux ressources d'un autre compte en changeant un identifiant.
- Autorisation par fonction (BFLA) : appeler une route d'administration avec un compte standard.
- Mass assignment : glisser un champ non prévu dans un corps de requête, comme un rôle ou un statut de paiement.
- Exposition excessive de données : une réponse qui renvoie l'objet complet quand l'interface n'en affiche que trois champs.
- Authentification et jetons : validation de signature JWT, algorithme accepté, expiration, révocation, rafraîchissement.
- Spécificités GraphQL : introspection ouverte, requêtes imbriquées coûteuses, contrôles posés sur la route au lieu du résolveur, aliasing pour contourner les limites.
- Injections côté serveur : SQL et NoSQL dans les filtres, SSRF sur les paramètres qui déclenchent un appel sortant.
- Abus de débit et de logique : absence de limite sur les routes sensibles, opérations rejouables, énumération de comptes.
Comment se passe une mission.
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, plus un jeu de comptes distincts : au minimum deux comptes du même niveau, pour tester l'accès horizontal, et un compte de chaque niveau de privilège.
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 accessibles depuis l'extérieur, routes de débogage laissées actives.
Matrice d'autorisation
Le cœur du travail. Pour chaque route sensible, je rejoue la même requête avec chaque rôle et avec les identifiants d'objets appartenant à d'autres comptes. Cette matrice est ce qui distingue un audit d'API sérieux d'une simple passe de scanner : elle est mécanique, exhaustive, et elle trouve.
Manipulation des données
Champs supplémentaires injectés dans les corps de requête, types modifiés, valeurs limites, structures imbriquées inattendues. On cherche ce que le serveur accepte alors qu'il ne devrait pas.
Rapport, débrief, retest
Rapport priorisé par criticité réelle, avec pour chaque faille la requête exacte qui la démontre, ce qu'un attaquant en tirerait, et la correction à apporter. Débrief avec l'équipe, puis retest de chaque correctif, inclus.
Ce que ça donne en pratique.
Failles réelles, trouvées, signalées et corrigées. Les clients et les périmètres ne sont jamais divulgués.
Combien ça coûte.
Sur devis, comme toutes mes missions. Sur une API, deux variables dominent tout le reste.
Le nombre d'endpoints sensibles, d'abord : pas le nombre total de routes, mais celles qui manipulent des données ou des droits. Et le nombre de rôles, ensuite. Ces deux chiffres se multiplient : la matrice d'autorisation à vérifier est le produit des deux. Une API à quinze routes utiles et deux rôles se traite vite. À cent routes et six rôles, la charge de travail n'a plus rien de comparable.
S'ajoutent la présence de GraphQL, qui demande une approche spécifique, et celle de webhooks entrants ou d'intégrations tierces. Fournir une spécification OpenAPI à jour réduit sensiblement le temps de cartographie, donc le devis.
Questions fréquentes.
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 endpoints qu'aucun client ne consomme encore. À défaut, je cartographie 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 ». La très grande majorité des failles graves que je trouve 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.
Que se passe-t-il si l'API est en production ?
C'est le cas le plus fréquent et cela ne pose pas de problème. Les tests destructifs et les tests de charge sont exclus par défaut. Sur les endpoints d'écriture, je travaille sur des ressources créées pour l'occasion plutôt que sur vos données réelles.
Les autres prestations.
Test d'intrusion web
Si le risque porte aussi sur l'application elle-même, ses rôles et ses parcours utilisateur, c'est le test d'intrusion web qu'il vous faut.
DécouvrirAudit de sécurité WordPress
WordPress expose lui aussi une API REST, souvent ouverte par défaut et rarement auditée. C'est un cas particulier qui mérite sa propre approche.
DécouvrirFaites auditer votre API.
Dites-moi combien de routes sensibles et combien de rôles vous avez, et si vous disposez d'une spécification OpenAPI ou d'un schéma GraphQL. Je vous réponds avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.