PREUVE / Feuillet de consultation
Pentest d’API REST et GraphQL : préparer le périmètre
Mis à jour le
Inventorier les interfaces réellement utilisées
Un pentest d’API doit couvrir les interfaces qui portent les parcours du client grand compte. Une liste d’URL sans contexte ne suffit pas. Décrivez les fonctions, les versions, les applications clientes et les rôles autorisés. Pour REST, préparez une documentation des opérations ; pour GraphQL, convenez de la disponibilité du schéma et des fonctions pertinentes. La documentation peut être fournie par un canal sécurisé après accord, sans être déposée dans une demande commerciale.
Identifiez aussi les interfaces d’administration, les webhooks et les traitements asynchrones. Une API utilisée seulement par votre propre interface reste une partie de la surface de l’application. Le cabinet doit savoir quelles fonctions sont actives et quelles versions anciennes restent accessibles. Marquez les services tiers : leur présence dans votre parcours ne vous donne pas automatiquement l’autorisation de les faire tester.
Vérifier les autorisations par objet et par fonction
Les droits attendus doivent être exprimés dans une matrice. Un utilisateur peut-il lire uniquement ses propres dossiers, ceux de son équipe ou toute son organisation ? Quel rôle peut exporter, supprimer ou administrer ? Préparez des comptes et des objets fictifs pour comparer les comportements autorisés et refusés. Le test doit porter sur la décision côté serveur, pas seulement sur la visibilité d’un bouton dans le navigateur.
Le Top 10 OWASP API 2023 répertorie notamment les défauts d’autorisation au niveau des objets et des fonctions. Ce catalogue aide à formuler des risques ; il ne définit pas à lui seul tous les tests à effectuer. Demandez une méthode adaptée à votre logique métier. Un parcours d’invitation, une validation financière ou un export différé peut créer des cas qui ne se réduisent pas à une catégorie technique générale.
Encadrer les ressources et effets de bord
Certains essais peuvent solliciter la mémoire, le calcul ou un service facturé à l’usage. Définissez les limites avec le cabinet et l’exploitation. Les tests de disponibilité ou de déni de service ne sont pas implicitement autorisés. Pour GraphQL, discutez de la complexité des opérations et des volumes permis ; pour REST, des quotas et opérations coûteuses. Prévoyez un seuil d’arrêt et un contact capable d’interrompre rapidement un scénario.
Les fonctions qui envoient des messages, déclenchent un paiement ou appellent un partenaire doivent être simulées ou bornées dans un environnement adapté. Un jeu de données fictif doit rester reconnaissable dans les traces. Expliquez le nettoyage attendu après audit. Une donnée créée pendant les tests peut sinon être reprise par une tâche planifiée et produire un effet réel plusieurs heures après la fin de la session d’audit.
Préparer authentification et dépendances
Fournissez plusieurs rôles selon le périmètre approuvé. Convenez de la durée des accès, des mécanismes MFA et de la révocation. Les jetons doivent être transmis hors du formulaire public et ne pas apparaître dans le rapport destiné au commercial. Le cabinet doit connaître les changements d’identité possibles : connexion fédérée, renouvellement de session ou changement d’organisation. Ces transitions sont souvent pertinentes pour la séparation des droits.
Distinguez ce que vous maîtrisez de ce qui relève du fournisseur d’identité ou d’un service distant. Votre configuration et votre intégration peuvent être examinées sans attaquer l’infrastructure du tiers. La consultation doit expliciter cette frontière. Si un accès de test externe dépend d’un accord du fournisseur, obtenez cet accord avant de confirmer les dates et documentez la limitation lorsqu’il n’est pas disponible.
Exiger une restitution exploitable
Le rapport doit identifier la version d’API, le rôle utilisé et les conditions du constat. Les exemples de requêtes doivent être expurgés des secrets et données réelles. Demandez comment les fonctions non testées sont signalées. Une couverture partielle peut être acceptable si elle répond à la clause client et si les limites sont connues. Elle ne doit pas être masquée sous une affirmation d’audit de toutes les interfaces.
Après correction, préparez un retest des chemins concernés et des contrôles associés. Une modification d’autorisation peut affecter plusieurs endpoints qui partagent le même composant. Le cabinet et votre équipe décident des scénarios de reprise à partir de la cause et du risque. Le commercial dispose d’une synthèse qui précise l’état vérifié sans diffuser des traces sensibles ou promettre une protection complète de l’API.
Grille de vérification avant commande
Pour « Pentest d’API REST et GraphQL : préparer le périmètre », conservez les réponses suivantes dans votre dossier achat. Une case vide devient une demande de clarification. Elle ne doit pas être interprétée comme un engagement inclus dans le prix ou comme une preuve déjà disponible.
- Inventaire des endpoints, schémas, rôles et applications clientes. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Couvrir autorisations objet/fonction, abus métier et limites de ressources. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Référencer OWASP API 2023 sans le confondre avec un protocole de test exhaustif. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
| Décision | Pièce à conserver | Responsable à désigner |
|---|---|---|
| Périmètre et exclusions acceptés | Version de la consultation et réponse détaillée du candidat, avec les interfaces et rôles concernés | Responsable technique de l’application |
| Format de preuve attendu | Confirmation du grand compte sur les documents, la langue et les conditions de revue | Interlocuteur commercial avec l’équipe sécurité client |
| Traitement des résultats | Plan de correction, critères de recette et conditions de retest proposées au devis | Équipe de développement et décideur de risque |
| Autorisation et diffusion | Mandat validé et droits de partage du rapport ou de la synthèse expurgée | Personne habilitée à engager la mission |
La consultation doit conserver les hypothèses qui peuvent changer le prix ou la date : accès non prêts, fonction indisponible, nouvelle version ou extension du périmètre. Demandez au cabinet comment une modification sera approuvée. Le rapport doit refléter la prestation effectivement réalisée. Une correction future, une disponibilité souhaitée et l’accord du grand compte restent des éléments à confirmer, chacun par son responsable.
Sources primaires consultées
Vérification éditoriale : 1er octobre 2026. Les conseils de consultation de ce feuillet sont une application pratique à discuter avec vos responsables et le cabinet.