Service 1.2
Test d’intrusion d’API.
Nous testons votre API directement, pas seulement à travers votre application : chaque point d’accès, avec les clés de chaque rôle, pour vérifier ce que chaque appelant peut lire et modifier.
1 Ce que nous testons
- Autorisation sur chaque objet : un appelant peut-il lire ou modifier les données d’un autre compte en changeant un identifiant ?
- Autorisation sur chaque fonction : un appelant ordinaire peut-il atteindre des points d’accès réservés aux administrateurs ou à d’autres rôles ?
- Authentification et jetons : comment les clés et les jetons sont émis, vérifiés, renouvelés et révoqués.
- Affectation de masse : les champs qu’un appelant peut remplir sans en avoir le droit, comme un rôle, un prix ou un propriétaire.
- Limites de débit : un seul appelant peut-il saturer la connexion, les recherches coûteuses ou les fonctions payantes ? Vérifié par de courtes rafales, jamais par un test de charge.
- Traitement des entrées en REST comme en GraphQL, y compris l’exposition du schéma GraphQL et les requêtes très imbriquées.
Méthode : OWASP API Top 10, OWASP WSTG, NIST SP 800-115.
2 Hors périmètre
Tests de charge, API tierces que vous appelez sans les exploiter.
3 Ce que vous fournissez
- Un fichier OpenAPI ou une collection Postman, ou la documentation qu’utilisent vos propres développeurs.
- Des clés ou des comptes pour chaque rôle, et deux pour tout rôle dont les utilisateurs ne doivent pas voir les données des autres.
- L’environnement à tester, production ou préproduction, et son URL de base.
- Un contact joignable pendant les fenêtres de test.
- Si une passerelle ou une limite de débit risque de nous bloquer, une liste d’autorisation pour nos adresses IP fixes. Nous vous les envoyons avant le test.
4 Déroulé du test
- Appel de cadrage : nous fixons les points d’accès, les rôles, les fenêtres de test et les personnes à appeler. Vous recevez une offre écrite avec les dates et le prix.
- Vous signez l’autorisation. Rien n’atteint votre API avant cela.
- Nous recensons chaque point d’accès, à partir de votre documentation et du trafic de votre propre application.
- Chaque point d’accès est testé avec chaque rôle, puis sans aucune clé.
- Une vulnérabilité critique est signalée à votre contact dès qu’elle est prouvée, sans attendre le rapport.
- Rapport et restitution, puis un contre-test une fois les corrections faites.
5 Ce que vous recevez
| Document | Contenu | Pour |
|---|---|---|
| Rapport technique | Chaque vulnérabilité avec son chemin d’exploitation, sa preuve, son score CVSS 4.0, sa CWE et sa correction. | Développeurs, DSI |
| Rapport de synthèse | Cinq à huit pages sur le risque métier, en langage clair. | Direction, conseil d’administration |
| Plan de remédiation | Les vulnérabilités classées par ordre de correction. | DSI, chefs de projet |
| Restitution | Une séance à distance pour parcourir les résultats et répondre aux questions. | Les deux |
| Attestation de contre-test | La preuve que les vulnérabilités ont été corrigées. | Auditeurs, clients |
6 Questions
- Combien de temps dure le test ?
- Cela dépend du nombre de points d’accès et de rôles. L’offre écrite donne le nombre de jours de test et les dates avant que vous signiez.
- Nous n’avons pas de documentation. Pouvez-vous tester quand même ?
- Oui. Nous reconstituons l’API à partir du trafic de votre application. Cela prend plus de temps, et l’offre en tient compte.
- Testez-vous les API d’autres entreprises que nous appelons ?
- Non. Seulement les API que vous exploitez. Tester l’API de quelqu’un d’autre demande l’accord de son propriétaire.
- Est-ce le même test que celui de l’application web ?
- Les deux se recoupent. Le test web atteint l’API à travers vos écrans. Le test d’API appelle chaque point d’accès directement, y compris ceux qu’aucun écran n’utilise.
Demander un devis pour ce test
Dites-nous ce qu’il faut tester. Un testeur vous répond avec une offre écrite : périmètre, dates et prix.
Demander un devis