Testeur de mutation de contrat API

Applique des mutations semantiques aux champs OpenAPI et peut les envoyer a un backend reel pour mesurer la validation defensive

Collez un document OpenAPI 3.x. Loutil derive dabord des requetes valides pour chaque operation, puis transforme certains champs en variantes risquées: suppression dun champ requis, nombre negatif, enum invalide, chaine composee despaces ou charge speciale.

Mode demploi :

  • Specification OpenAPI : collez YAML ou JSON
  • URL de base : laissez vide pour un plan hors ligne, ou pointez vers un backend reel
  • Executer les mutations : envoie vraiment les requetes mutees
  • En-tete dautorisation : accepte par exemple Bearer
  • Mutations par champ : limite le nombre de variantes generees par champ
  • Delai de requete : fixe la duree max dune requete

Lecture du resultat :

  • defended : le backend a rejete la mutation
  • accepted : le backend a quand meme repondu avec succes
  • documented : le code observe existe dans les responses OpenAPI

Exemples de résultats

1 Exemples

Verifier quun endpoint dinscription rejette bien les mutations semantiques

Genere des omissions, valeurs negatives et caracteres speciaux depuis le contrat OpenAPI.

{
  "summary": {
    "operations": 1,
    "generatedMutations": 8,
    "executedMutations": 0,
    "acceptedMutations": 0,
    "defendedMutations": 0
  },
  "mutations": [
    {
      "fieldPath": "body.email",
      "mutation": "Inject special characters"
    },
    {
      "fieldPath": "body.age",
      "mutation": "Negative numeric mutation"
    }
  ]
}
Voir paramètres d'entrée
{ "openApiSpec": "openapi: 3.0.3\npaths:\n /users:\n post:\n requestBody:\n required: true\n content:\n application/json:\n schema:\n type: object\n required: [email, role, age]\n properties:\n email: { type: string, minLength: 5 }\n role: { type: string, enum: [admin, member] }\n age: { type: integer, minimum: 18 }\n responses:\n \"201\": { description: created }\n \"400\": { description: invalid }\n", "baseUrl": "", "executeMutations": false, "authorizationHeader": "", "mutationsPerField": 3, "timeoutMs": 8000 }

Points clés

Catégorie
Développement et Web
Types d’entrée
textarea, text, checkbox, number
Type de sortie
json
Couverture des échantillons
4
API disponible
Yes

Vue d’ensemble

Le Testeur de mutation de contrat API est un outil conçu pour évaluer la robustesse de votre backend en appliquant des mutations sémantiques aux champs de vos requêtes OpenAPI. En générant des variantes risquées telles que l'omission de champs requis, l'injection de caractères spéciaux ou des valeurs hors limites, il vous permet de vérifier si votre API rejette correctement les données invalides (validation défensive) ou si elle les accepte par erreur.

Quand l’utiliser

  • Lors de l'audit de sécurité d'une API pour identifier les failles de validation des données entrantes.
  • Avant le déploiement d'une nouvelle version de votre contrat OpenAPI pour s'assurer que les règles de validation sont correctement implémentées côté serveur.
  • Pour automatiser les tests de robustesse (fuzzing sémantique) sur des endpoints spécifiques sans écrire de scripts manuels.

Comment ça marche

  • Collez votre spécification OpenAPI 3.x (au format YAML ou JSON) dans le champ dédié.
  • L'outil analyse les opérations documentées et génère des requêtes de base valides, puis crée des mutations pour chaque champ (valeurs négatives, enums invalides, etc.).
  • Si vous renseignez une URL de base et activez l'exécution, l'outil envoie réellement les requêtes mutées au backend en utilisant l'en-tête d'autorisation fourni.
  • Consultez le rapport final pour voir quelles mutations ont été défendues (rejetées par le serveur) ou acceptées à tort, et si les codes de retour sont documentés.

Cas d’usage

Vérification de la gestion des erreurs sur un endpoint d'inscription utilisateur (ex: âge négatif, email sans format valide).
Test de résilience d'une API financière face à des montants de transaction inattendus ou des types de devises non répertoriés.
Validation de la conformité stricte entre l'implémentation du backend et le contrat OpenAPI fourni aux clients.

Exemples

1. Vérifier la validation d'un endpoint d'inscription

Ingénieur QA
Contexte
L'équipe vient de livrer une nouvelle API d'inscription d'utilisateurs. Le contrat OpenAPI spécifie que l'email est requis et que l'âge doit être supérieur à 18.
Problème
S'assurer que le backend ne crée pas de comptes si des champs obligatoires manquent ou si des valeurs absurdes sont envoyées.
Comment l’utiliser
Collez le YAML de l'API dans 'Spécification OpenAPI', laissez l'URL de base vide pour générer le plan, et fixez 'Mutations par champ' à 3.
Configuration d’exemple
executeMutations: false, mutationsPerField: 3
Résultat
L'outil génère un rapport JSON listant les mutations prévues, comme l'omission du champ email ou l'injection d'un âge négatif, prêt à être analysé.

2. Tester la robustesse d'une API en production

Développeur Backend
Contexte
Une API de gestion de produits est en ligne, mais des doutes subsistent quant à la validation stricte des catégories (enum) et des prix.
Problème
Envoyer de vraies requêtes malformées au serveur de staging pour voir s'il renvoie bien des erreurs 400.
Comment l’utiliser
Collez le JSON OpenAPI, renseignez l'URL de base du serveur de staging, ajoutez le token Bearer, et cochez 'Exécuter les mutations'.
Configuration d’exemple
baseUrl: 'https://staging-api.example.com', executeMutations: true, authorizationHeader: 'Bearer abc123_token'
Résultat
Le rapport indique quelles requêtes ont été 'defended' (rejetées avec succès) et met en évidence les failles où le serveur a répondu 'accepted' malgré des données invalides.

Tester avec des échantillons

development

Hubs associés

FAQ

Quels formats de spécification sont pris en charge ?

L'outil accepte les documents OpenAPI 3.x au format YAML ou JSON.

Est-il obligatoire d'envoyer les requêtes à un vrai serveur ?

Non, si vous laissez l'URL de base vide, l'outil générera uniquement un plan de mutation hors ligne pour vous montrer les requêtes qui seraient testées.

Que signifie le statut 'defended' dans les résultats ?

Cela indique que votre backend a correctement identifié la requête mutée comme invalide et l'a rejetée avec un code d'erreur approprié.

Comment limiter le nombre de requêtes générées ?

Vous pouvez ajuster le paramètre 'Mutations par champ' (entre 1 et 6) pour contrôler le volume de variantes créées pour chaque paramètre.

Puis-je tester des API nécessitant une authentification ?

Oui, vous pouvez fournir un jeton dans le champ 'En-tête d'autorisation' (par exemple, 'Bearer <token>') pour authentifier les requêtes mutées.

Documentation de l'API

Point de terminaison de la requête

POST /fr/api/tools/api-contract-mutation-tester

Paramètres de la requête

Nom du paramètre Type Requis Description
openApiSpec textarea Oui -
baseUrl text Non -
executeMutations checkbox Non -
authorizationHeader text Non -
mutationsPerField number Non -
timeoutMs number Non -

Format de réponse

{
  "key": {...},
  "metadata": {
    "key": "value"
  },
  "error": "Error message (optional)",
  "message": "Notification message (optional)"
}
Données JSON: Données JSON

Documentation de MCP

Ajoutez cet outil à votre configuration de serveur MCP:

{
  "mcpServers": {
    "elysiatools-api-contract-mutation-tester": {
      "name": "api-contract-mutation-tester",
      "description": "Applique des mutations semantiques aux champs OpenAPI et peut les envoyer a un backend reel pour mesurer la validation defensive",
      "baseUrl": "https://elysiatools.com/mcp/sse?toolId=api-contract-mutation-tester",
      "command": "",
      "args": [],
      "env": {},
      "isActive": true,
      "type": "sse"
    }
  }
}

Vous pouvez chaîner plusieurs outils, par ex.: `https://elysiatools.com/mcp/sse?toolId=png-to-webp,jpg-to-webp,gif-to-webp`, max 20 outils.

Si vous rencontrez des problèmes, veuillez nous contacter à [email protected]