Tests de securite API : 10 choses que tout debutant doit savoir

Les API alimentent pratiquement toutes les applications modernes. Lorsque vous ouvrez une application mobile, consultez votre solde bancaire, commandez un repas ou mettez a jour votre profil, une API travaille en arriere-plan. Le site web est la partie visible. L'API est la partie qui envoie, recoit et traite les donnees.

C'est aussi pourquoi les API sont l'une des cibles les plus importantes pour les tests de securite. Un site web peut sembler securise de l'exterieur, mais l'API qui le soutient peut encore exposer des donnees privees, conduisant a une fuite de donnees, ou accepter des actions provenant du mauvais utilisateur. De nombreux bugs API serieux ne sont pas trouves grace a des charges utiles complexes. Ils sont trouves en lisant attentivement les requetes, en changeant de petites valeurs, et en posant une seule question : cet utilisateur devrait-il etre autorise a faire cela ?

Ce guide vous accompagne a travers tout ce dont vous avez besoin pour commencer les tests de securite API, en partant de zero.

1. Qu'est-ce que la securite API et pourquoi est-elle importante ?

Pour les utilisateurs normaux, l'application est l'ecran qu'ils voient. Pour les testeurs de securite, la vraie application vit dans le trafic API. Chaque clic de bouton, mise a jour de profil, telechargement de fichier, action de paiement et changement de mot de passe genere une requete API.

L'API est l'endroit ou resident les donnees les plus sensibles. Si une API n'est pas correctement protegee, le frontend ne peut pas la sauver. Un bouton peut etre cache, mais la requete peut toujours etre envoyee manuellement. Un champ peut etre desactive dans le navigateur, mais il peut toujours etre modifie dans Burp Suite. Une application mobile peut masquer des donnees a l'ecran, mais la reponse API complete peut encore les contenir.

La regle est simple : ne faites jamais confiance uniquement a ce que l'interface utilisateur affiche. Le frontend est la couche de presentation. La vraie securite doit se produire cote serveur. Le serveur doit verifier qui est l'utilisateur, a quoi il est autorise a acceder, et si les donnees qu'il a soumises meritent confiance.

En tant que debutant, c'est une bonne nouvelle. Vous n'avez pas besoin de competences d'exploitation hautement avancees. Si vous comprenez l'authentification, l'autorisation, les reponses API et la modification basique de requetes, vous pouvez deja commencer a trouver de vrais problemes de securite API.

2. Comment un seul bug IDOR explique les tests de securite API

Il etait environ 23 heures quand Arjun, un chasseur de bug bounty debutant, testait une plateforme de recrutement. Il apprenait depuis seulement quelques mois. Il a cree un compte, s'est connecte, a ouvert son profil et a commence a observer les requetes dans Burp Suite.

Une requete a attire son attention. L'endpoint API ressemblait a /api/v1/users/1147/profile. La reponse affichait les details de son propre profil : nom, adresse e-mail, numero de telephone et adresse enregistree. Tout semblait normal. Mais ensuite, il a remarque le nombre dans l'URL. Cela ressemblait a un identifiant utilisateur.

Par curiosite, il a change 1147 en 1148 et a renvoye la requete. Il s'attendait a une erreur. Peut-etre 403 Forbidden. Peut-etre 404 Not Found. Au lieu de cela, l'API a renvoye le profil complet d'un autre utilisateur. Il a change le nombre a nouveau. Un autre profil est apparu.

Arjun avait trouve un Broken Object Level Authorization, egalement connu sous le nom de BOLA ou IDOR. L'API verifiait qu'il etait connecte, mais elle ne verifiait pas si le profil demande lui appartenait reellement. C'est l'une des erreurs de securite API les plus courantes et les plus dangereuses.

La lecon : Arjun n'a pas utilise un exploit complexe. Il n'a pas contourne un pare-feu. Il a simplement change une valeur dans une requete API, et le serveur a renvoye des donnees qui auraient du etre protegees.

J'ai vu ce schema exact des centaines de fois a travers mes 250+ entrees au Hall of Fame. BOLA est systematiquement le premier vrai bug que mes etudiants trouvent, et il reste la vulnerabilite IDOR la plus courante dans la realite. La technique est simple, mais l'impact est presque toujours critique.

3. Les 6 prerequis avant de tester les API

Avant de commencer a tester les API, vous avez besoin d'une base. Vous n'avez pas besoin de tout maitriser, mais vous devez comprendre ce qui se passe lorsque vous envoyez une requete et recevez une reponse.

1. Materiel informatique et reseaux. Comprenez comment les appareils utilisent les reseaux pour partager des donnees. Apprenez ce que font les adresses IP, le DNS et les routeurs. Familiarisez-vous avec le modele OSI.

2. Ligne de commande et Linux. Vous devez etre a l'aise avec les commandes Linux de base et une distribution de test comme Kali Linux. Lisez des fichiers, executez des outils, envoyez des requetes et formatez des reponses JSON. Apprenez le scripting basique en Bash ou Python pour l'automatisation.

3. Fondamentaux HTTP. Les API fonctionnent via des requetes HTTP. Une requete possede une methode, des en-tetes, et parfois un corps ou des parametres. Connaissez les methodes courantes : GET (lire), POST (creer), PUT/PATCH (mettre a jour), DELETE (supprimer). Connaissez les codes de statut : 200 (succes), 401 (non autorise), 403 (interdit), 404 (non trouve), 500 (erreur serveur).

4. Authentification vs. autorisation. L'authentification signifie prouver qui vous etes, comme se connecter avec un mot de passe. L'autorisation signifie decider ce que vous etes autorise a faire apres la connexion. Un utilisateur normal et un administrateur peuvent tous deux etre connectes, mais ils ne devraient pas avoir les memes permissions. De nombreux bugs API serieux surviennent parce que l'authentification existe mais l'autorisation est faible ou absente. Apprenez les types courants : Basic, Token-based, JWT, Session, SSO et OAuth.

5. Types et structure des API. Une API est un moyen pour deux systemes de communiquer. Le client envoie une requete, le serveur renvoie des donnees, generalement en JSON. Connaissez les types principaux : REST (le plus courant, utilise des URL standard et des methodes HTTP), GraphQL (endpoint unique, le client specifie exactement les donnees qu'il veut), SOAP (plus ancien, base sur XML, encore utilise dans la banque), WebSockets (communication en temps reel), et gRPC (rapide, moderne, de service a service). Commencez par REST, puis passez a GraphQL.

6. Burp Suite et Postman. Ce sont les outils les plus importants pour les tests API. Burp Suite vous permet de capturer des requetes, modifier des valeurs et observer les reponses du serveur. Postman vous aide a construire et organiser des requetes API. Passez du temps dans ces outils au lieu de seulement regarder des tutoriels.

4. Les 5 vulnerabilites API que vous verrez le plus souvent

Il existe de nombreux types de vulnerabilites API, mais certaines reviennent sans cesse. Ce sont celles que tout debutant devrait apprendre en premier.

4.1 Broken Object Level Authorization (BOLA/IDOR)

BOLA se produit lorsqu'une API vous permet d'acceder a un objet qui ne vous appartient pas. Un objet peut etre un profil, une commande, une facture, un ticket, un fichier, un message ou un moyen de paiement.

Imaginez que vous ouvrez les details de votre commande. La requete API ressemble a /api/v1/orders/8842. Le serveur verifie votre token et renvoie la commande. Maintenant, vous changez 8842 en 8843, et le serveur renvoie la commande de quelqu'un d'autre. C'est BOLA.

L'erreur est simple : l'API a verifie que vous etiez connecte, mais elle n'a pas verifie si la commande 8843 appartenait a votre compte. BOLA detient la premiere position du OWASP API Security Top 10 depuis la premiere publication de la liste.

Comment tester BOLA :

• Recherchez chaque requete contenant un identifiant (identifiant utilisateur, identifiant de commande, identifiant de facture, identifiant de ticket, UUID, GUID)
• Changez l'identifiant et observez la reponse
• Utilisez deux comptes et testez si le compte A peut acceder aux donnees du compte B
• Verifiez a la fois les identifiants numeriques sequentiels et les UUID

4.2 Broken authentication

Broken authentication signifie que le systeme presente une faiblesse dans la facon dont il verifie les utilisateurs ou gere les sessions. Dans les tests API, cela implique generalement les tokens, les flux de reinitialisation de mot de passe, le comportement de deconnexion et les systemes OTP.

Problemes courants a tester :

• Tokens de rafraichissement qui n'expirent jamais. Un token d'acces peut expirer en 15 minutes, mais si le token de rafraichissement n'expire jamais, un token de rafraichissement vole signifie un acces permanent
• Deconnexion uniquement cote client. L'application supprime le token du stockage, mais le serveur l'accepte toujours. Une deconnexion correcte doit invalider la session cote serveur
• Tokens de reinitialisation de mot de passe reutilisables. Un token de reinitialisation doit etre aleatoire, expirer rapidement et fonctionner une seule fois. S'il peut etre reutilise ou devine, l'impact s'eleve a la prise de controle du compte
• Pas de limitation de debit sur l'OTP. Si l'API autorise des tentatives OTP illimitees sans mesures de protection de l'authentification a deux facteurs, un attaquant peut utiliser la force brute ou le credential stuffing pour contourner le code

4.3 Broken Object Property Level Authorization

Cette categorie couvre deux problemes lies : Excessive Data Exposure et Mass Assignment.

Excessive Data Exposure se produit lorsque l'API renvoie plus d'informations que ce dont le frontend a besoin. Les developpeurs envoient parfois des objets de base de donnees complets au client et font confiance au frontend pour n'afficher que les champs securises.

Par exemple, une page d'avis peut n'afficher que le nom du redacteur et le commentaire. Mais la reponse API peut aussi contenir l'adresse e-mail du redacteur, son numero de telephone, son identifiant utilisateur interne et son code de departement. Le site web masque ces champs, mais quiconque interceptant la reponse les voit.

Mass Assignment se produit lorsque l'API accepte plus de champs de la part de l'utilisateur qu'elle ne le devrait. Les developpeurs lient parfois le corps complet de la requete a l'objet de base de donnees et oublient de bloquer les champs sensibles.

Par exemple, une page de mise a jour de profil peut permettre de changer uniquement le nom et le numero de telephone. Mais si l'API accepte aussi role, isAdmin, isVerified ou accountBalance, l'utilisateur peut modifier des valeurs qu'il ne devrait jamais controler.

Comment tester :

• Pour l'exposition de donnees : inspectez chaque reponse JSON brute dans Burp Suite. Recherchez des champs comme email, phone, isAdmin, token, role, internalId
• Pour l'assignation de masse : ajoutez des champs supplementaires dans les corps de requete. Essayez "role": "admin", "isVerified": true, "plan": "enterprise" et verifiez si l'API les accepte

4.4 Broken Function Level Authorization

Cela se produit lorsqu'un utilisateur peut effectuer une action que seul un autre role devrait etre autorise a effectuer. Contrairement a BOLA (acceder aux donnees d'un autre utilisateur), il s'agit ici d'executer une fonction que votre role ne devrait pas avoir.

Un utilisateur normal ne devrait pas pouvoir appeler des endpoints administrateur qui creent des utilisateurs, suppriment des comptes, approuvent des paiements ou exportent des donnees d'entreprise. C'est en fait une forme d'escalade de privileges. Meme si le bouton administrateur est cache de l'interface utilisateur, l'endpoint API necessite toujours des verifications de permissions cote serveur.

Approche de test :

• Cartographiez tous les endpoints et comprenez quelles actions appartiennent a quel role
• Capturez une requete d'un compte a privilege eleve et rejouez-la avec un token a privilege inferieur
• Recherchez des champs de requete comme role, isAdmin, type, privilege, accessLevel
• Le serveur ne devrait jamais faire confiance au role envoye par le client

4.5 Unrestricted Resource Consumption

Cela se produit lorsqu'une API permet aux utilisateurs de consommer des ressources excessives : memoire, CPU, stockage, bande passante ou couts de services tiers.

Par exemple, une API produit renvoie normalement 20 resultats par page avec limit=20. Si vous le changez en limit=999999 et que le serveur tente de tout renvoyer, l'API peut ralentir ou planter. Un endpoint de generation PDF qui accepte pageCount=99999 peut consommer toute la memoire disponible.

Parametres a tester : limit, pageSize, batchSize, count, quantity, width, height, duration, fileSize, pageCount.

Attention : de nombreux programmes de bug bounty n'autorisent pas les tests de deni de service. Restez toujours dans le perimetre et testez avec precaution.

5. Le OWASP API Top 10 explique

Le OWASP API Security Top 10 est la liste de reference des risques de securite API. La mise a jour 2023 a reorganise plusieurs categories :

Pour les debutants, concentrez-vous d'abord sur ceux-ci :

1. API1 - Broken Object Level Authorization
2. API2 - Broken Authentication
3. API3 - Broken Object Property Level Authorization
4. API4 - Unrestricted Resource Consumption
5. API5 - Broken Function Level Authorization

Les cinq categories restantes meritent attention a mesure que vos competences en hacking API progressent :

• API6 - Unrestricted Access to Sensitive Business Flows : abus automatise de la logique metier (scalping de billets, creation massive de comptes)
• API7 - Server-Side Request Forgery (SSRF) : forcer le serveur a effectuer des requetes vers des services internes via des URL fournies par l'utilisateur
• API8 - Security Misconfiguration : politiques CORS permissives, erreurs verbeuses, TLS manquant, endpoints de debug exposes
• API9 - Improper Inventory Management : API fantomes, anciennes versions non corrigees (testez toujours /api/v1/ quand /api/v2/ existe), et documentation Swagger exposee
• API10 - Unsafe Consumption of Third-Party APIs : faire confiance aux reponses d'API externes sans validation

Les debutants devraient d'abord devenir solides sur API1 a API5. Une fois que vous comprenez le controle d'acces, l'authentification, l'exposition de donnees et les limites de ressources a travers la pratique, la liste complete se cartographie naturellement sur des bugs que vous avez deja testes.

6. Comment mettre en place votre premier laboratoire de test API

Ne testez jamais des sites web au hasard sans autorisation. Les tests non autorises peuvent violer des lois comme le Computer Fraud and Abuse Act (CFAA) aux Etats-Unis, le Computer Misuse Act au Royaume-Uni, ou la legislation equivalente dans votre juridiction. Utilisez d'abord des laboratoires intentionnellement vulnerables pour pouvoir apprendre sans risque juridique. Pour un guide complet de configuration d'environnement, consultez notre guide de configuration de laboratoire de cybersecurite.

Configuration etape par etape :

1. Installez Burp Suite Community Edition. Configurez le proxy du navigateur, installez le certificat CA de Burp et confirmez que vous pouvez capturer le trafic HTTPS. La Web Security Academy de PortSwigger propose un tutoriel gratuit.

2. Deployez crAPI (Completely Ridiculous API). Ce projet OWASP est concu specifiquement pour apprendre la securite API. Il inclut BOLA, broken authentication, excessive data exposure et d'autres vulnerabilites mappees sur l'API Top 10. C'est le meilleur point de depart.

3. Essayez VAmPI. Une API REST vulnerable simple pour pratiquer les tests d'authentification et d'autorisation.

4. Passez a DVGA. Une fois a l'aise avec les API REST, ce laboratoire enseigne les problemes specifiques a GraphQL comme l'abus d'introspection, la manipulation de requetes et l'autorisation cassee dans les resolvers.

La methode de pratique : ouvrez le laboratoire, utilisez-le normalement et capturez le trafic dans Burp Suite. Envoyez les requetes dans Repeater. Changez les identifiants. Supprimez les tokens. Changez les roles. Modifiez les corps de requete. Augmentez les limites. Rejouez d'anciens tokens. Lisez chaque reponse.

Prenez des notes pendant la pratique. Notez l'endpoint, ce que vous avez change, ce que le serveur a renvoye et pourquoi le comportement est incorrect. Cette habitude se traduit directement dans la redaction de vrais rapports de bugs et la construction de votre portfolio en securite.

7. Les 8 outils essentiels de test de securite API

Vous n'avez pas besoin d'une centaine d'outils. Au debut, comprenez-en quelques-uns en profondeur.

1. Burp Suite - Votre outil principal. Interceptez, modifiez, rejouez et comparez les requetes. Repeater est essentiel pour tester une requete avec de petites modifications.

2. Postman - Construisez des requetes API manuellement et organisez-les en collections. Utile quand vous connaissez l'endpoint et souhaitez un flux de travail structure.

3. jwt.io - Decodez les tokens JWT pour voir les claims comme l'identifiant utilisateur, le role, le delai d'expiration et l'emetteur. Ne pirate rien, mais vous aide a comprendre quelles informations le token transporte.

4. ffuf - Fuzzer web rapide pour decouvrir des chemins caches, des endpoints, des parametres et des valeurs.

5. Gobuster - Outil de decouverte de repertoires et fichiers. Complete ffuf pour un scan plus large.

6. Kiterunner - Decouverte de routes API concue specifiquement pour les chemins API. Plus adapte aux API que les outils generiques de brute force de repertoires.

7. gau / waybackurls - Collectez d'anciennes URL depuis les archives web pour trouver des endpoints API historiques comme /api/ ou /graphql.

8. Nmap - Decouvrez les ports ouverts et les services. Utilisez-le pour trouver des services API fonctionnant sur des ports non standards.

Pour l'analyse du trafic API au niveau reseau, Wireshark est egalement utile, surtout pour le debogage des problemes TLS et de la couche transport.

Les outils font gagner du temps, mais ils ne remplacent pas la reflexion. La plupart des bons bugs API sont trouves parce que le testeur comprend la logique, pas parce qu'un outil a affiche un resultat.

8. Comment trouver les endpoints API

Avant de trouver des bugs, vous devez trouver la surface API. Cela signifie decouvrir autant d'endpoints que possible.

Utilisez l'application. Connectez-vous, mettez a jour votre profil, telechargez un fichier, recherchez quelque chose, changez les parametres, creez une commande, annulez-la, invitez un utilisateur, consultez les notifications. Chaque action peut generer une requete API.

Examinez les fichiers JavaScript. Les applications web modernes stockent les chemins API dans le JavaScript. Recherchez des mots comme api, v1, v2, graphql, auth, token, upload, admin, payment, settings, internal.

Verifiez la documentation API. Les fichiers Swagger UI ou OpenAPI exposes revelent les endpoints, les parametres, les corps de requete, les exigences d'authentification et les exemples de reponses. Trouver une documentation exposee peut faire gagner des heures.

Scannez les sous-domaines. Les API resident souvent sur des sous-domaines comme api.example.com, mobile.example.com, dev.example.com ou staging.example.com. Les API plus anciennes ou de staging ont frequemment une securite plus faible.

Recherchez dans les archives web. Des outils comme gau et waybackurls revelent d'anciens endpoints qui existent toujours sur le serveur. Les recherches GitHub peuvent reveler des chemins API, de la documentation ou des cles fuites dans les depots publics.

L'objectif est de construire une carte complete avant de tester en profondeur. Si vous ne connaissez pas les endpoints, vous ne savez pas quoi tester.

Maintenant que vous comprenez ce que vous recherchez, construisons la methodologie pour trouver votre premier vrai bug.

9. Des laboratoires de securite API aux vrais programmes de bug bounty

Une fois a l'aise avec les laboratoires, commencez a tester de vrais programmes. Ne precipitez pas cette etape.

Avant de tester :

• Lisez le perimetre du programme. Assurez-vous que les tests API sont autorises
• Verifiez quels domaines et applications sont dans le perimetre
• Verifiez si le scanning automatise ou les tests DoS sont restreints
• Comprenez les attentes du programme en matiere de divulgation responsable

Votre methodologie de depart :

1. Capturez le trafic et cartographiez tous les endpoints API
2. Comprenez les roles et permissions des utilisateurs
3. Testez l'acces au niveau objet (BOLA/IDOR)
4. Inspectez toutes les reponses API pour l'exposition excessive de donnees
5. Testez le comportement d'authentification (expiration des tokens, deconnexion, reinitialisation de mot de passe)
6. Verifiez si les utilisateurs normaux peuvent appeler les fonctions administrateur
7. Documentez tout au fur et a mesure

Suivre cette checklist de securite API pour chaque cible construit la coherence. Votre premier rapport valide vous apprendra plus que n'importe quel cours. Votre premier rejet vous apprendra aussi quelque chose. Les rejets font partie du bug bounty : parfois le probleme n'est pas suffisamment impactant, parfois il est deja connu, parfois vos etapes ne sont pas claires. Lisez la reponse, ameliorez votre methode et continuez a tester.

10. Ressources de pratique et prochaines etapes

La pratique et la lecture de vrais rapports doivent aller de pair. Les laboratoires vous aident a comprendre le bug. Les vrais rapports vous aident a comprendre l'impact et le style de rapport.

Laboratoires et cours :

• PortSwigger Web Security Academy - Formation gratuite et complete en securite web avec des modules axes sur les API
• crAPI - Laboratoire de securite API dedie construit par l'OWASP
• VAmPI - API REST vulnerable pour les tests d'authentification
• Kontra - Explications interactives des vulnerabilites
• APIsec University - Cours dedies a la securite API

Livres :

• Hacking APIs par Corey Ball - Le guide pratique de reference pour les tests de penetration API
• Black Hat GraphQL par Nick Aleks et Dolev Farhi - Plongee approfondie dans la securite GraphQL

Lisez les rapports divulgues. Recherchez sur HackerOne et Bugcrowd les rapports tagges API, IDOR, BOLA, broken authentication et excessive data exposure. Lire quelques rapports chaque semaine entraine votre reconnaissance de schemas.

Exemples de Google dork pour trouver des rapports publics :

• site:hackerone.com/reports/* intext:API
• site:hackerone.com/reports/* intext:IDOR
• site:hackerone.com/reports/* intext:GraphQL

Votre parcours d'apprentissage :

Si vous partez de zero, suivez cette sequence : apprenez HTTP et JSON, puis Burp Suite. Pratiquez sur crAPI. Comprenez BOLA en profondeur. Passez a broken authentication, excessive data exposure, function-level authorization et les limites de ressources. Lisez de vrais rapports. Commencez les programmes de bug bounty. Validez vos competences avec des certifications de cybersecurite pour debutants pour voir ou les tests de securite API s'integrent dans le paysage plus large de la securite offensive.

Votre premier bug API peut provenir du changement d'un seul identifiant, du rejeu d'un seul token, ou de la detection d'un seul champ cache dans une reponse JSON. Les tests de securite API ne consistent pas a memoriser des charges utiles. Il s'agit de comprendre la confiance et d'appliquer les meilleures pratiques de securite API a chaque couche. L'API peut-elle faire confiance a cet utilisateur ? Peut-elle faire confiance a cet identifiant ? Peut-elle faire confiance a cette valeur de role ? La plupart des bugs API surviennent lorsque le serveur fait confiance a quelque chose qu'il devrait verifier.

C'est exactement pourquoi les tests de penetration API sont un point de depart si puissant pour votre carriere en cybersecurite.