TL;DR : L'entrée de votre API est une surface d'attaque : testez-la comme telle. Rédigez des cas négatifs qui envoient des champs surdimensionnés, des types erronés, des corps mal formés et des chaînes d'injection, puis vérifiez que le point de terminaison répond par un 4xx, jamais par un 5xx. Transformez la validation de schéma en contrôle de sécurité avec additionalProperties: false, des énumérations et des limites de longueur. Exécutez la suite complète en CI à chaque modification. Les agents IA rendent cela urgent : ils génèrent et transmettent des charges utiles à la vitesse de la machine, de sorte que « charger ces données » qui devient « exécuter ce code » prend désormais de l'ampleur.
La plupart des suites de tests prouvent que votre API fonctionne lorsque l'appelant est poli : vous envoyez un corps valide, vous obtenez un 200, l'assertion réussit. Ce résultat ne dit presque rien sur ce qui se passe lorsqu'un corps est hostile. Une entrée non fiable est toute donnée que votre point de terminaison n'a pas générée lui-même : corps de requêtes, chaînes de requête, en-têtes, fichiers téléversés, charges utiles de webhook et JSON assemblé à la volée par un agent IA. Traitez toutes ces entrées comme si quelqu'un finira par en envoyer la pire version possible.
