Test d'intrusion d'une API : ce qu'un hacker éthique vérifie

Pourquoi l'API est devenue la première cible

Une interface web ou mobile masque les données que l'utilisateur n'a pas le droit de voir. L'API, elle, répond à quiconque sait formuler la requête. Si le contrôle des droits est fait dans l'interface et pas sur le serveur, il suffit de modifier un identifiant dans un appel pour lire la commande, la facture ou le profil d'un autre client.

Ces failles ne se voient pas en naviguant sur le site. Un test de sécurité de l'application classique peut les manquer s'il ne descend pas au niveau des appels. C'est pour cela que l'API mérite un test dédié, avec sa documentation et des comptes de test de plusieurs niveaux.

Ce qu'un hacker éthique vérifie sur une API

• Contrôle d'accès objet par objet — Un utilisateur peut-il lire ou modifier une ressource qui ne lui appartient pas en changeant un identifiant dans l'URL ou le corps de la requête ? C'est la faille d'API la plus fréquente.
• Authentification et jetons — Robustesse de la connexion, durée de vie et révocation des jetons, signature des JWT, clés d'API exposées dans une application mobile ou un dépôt public.
• Droits par fonction — Un compte standard peut-il appeler une route réservée à l'administrateur, simplement parce qu'elle existe et n'est pas protégée côté serveur ?
• Données renvoyées en trop — Réponses qui contiennent des champs inutiles (adresse, téléphone, rôle, hachage de mot de passe) que l'interface n'affiche pas mais que l'API transmet.
• Injections et validation des entrées — Injection SQL ou NoSQL, affectation de masse (un champ « role » ou « prix » accepté alors qu'il ne devrait pas l'être), téléversement de fichiers.
• Limites de débit et abus — Absence de limite sur la connexion, la réinitialisation de mot de passe ou l'envoi de SMS, qui permet de deviner des comptes ou de faire exploser une facture.
• Versions et routes oubliées — Anciennes versions de l'API toujours en ligne, environnements de test accessibles, documentation ou console GraphQL ouvertes à tous.

REST, GraphQL, API mobile ou API partenaire

Une API REST se teste route par route, à partir de sa documentation OpenAPI ou d'une collection Postman. Une API GraphQL demande des vérifications propres : introspection laissée ouverte, requêtes imbriquées qui saturent le serveur, contrôle des droits champ par champ.

Une API appelée par une application mobile se teste souvent avec l'application elle-même, pour retrouver les routes et les clés qu'elle embarque. Une API ouverte à des partenaires ajoute la question des clés partagées et de ce que chaque partenaire peut réellement voir.

Préparer le test : ce qu'il faut fournir à l'expert

1. Le périmètre — La liste des domaines et des versions à tester, et ce qui est exclu (paiement réel, envoi de mails aux clients, services tiers).
2. La documentation — Fichier OpenAPI, collection Postman ou schéma GraphQL. Sans documentation, le test reste possible en boîte noire, mais il prend plus de temps.
3. Des comptes de test — Au moins deux comptes par niveau de droits (deux clients, un administrateur), pour vérifier qu'un compte ne voit pas les données de l'autre.
4. L'environnement — De préférence une préproduction identique à la production. Si le test porte sur la production, fixez ensemble les horaires et les limites.
5. L'autorisation écrite — Un test d'intrusion se mène uniquement sur un système que vous possédez ou que vous êtes autorisé à faire tester, avec une autorisation signée avant le début de la mission.

Les livrables d'un test d'intrusion d'API

Un rapport qui classe chaque faille par gravité, avec la requête exacte qui la reproduit et la correction proposée. Une synthèse lisible par la direction, séparée du détail technique destiné aux développeurs.

Demandez aussi une contre-vérification après correction : l'expert rejoue les requêtes et confirme que les failles sont fermées. C'est elle qui vous permet de répondre à un client, un partenaire ou un investisseur qui demande la preuve d'un test.

Comment se déroule la mission sur Hackersdate

Vous publiez votre besoin gratuitement : type d'API, nombre de routes, documentation disponible, environnement, délai. Les hackers éthiques vérifiés qui répondent dépensent un crédit par proposition : vous recevez des propositions ciblées, pas un envoi en masse.

Vous choisissez l'expert sur son profil, ses avis et son devis. Le paiement est déposé sur Stripe et reste bloqué jusqu'à la livraison du rapport, que vous validez avec un avis obligatoire. Hackersdate prélève une commission de 2 %.