Des entrées valides aux sens très différents
Un document JSON peut être un objet, un tableau ou une valeur simple. null est donc valide même si votre contrat exige un objet. Certains nombres dépassent la précision entière de JavaScript, et des noms de propriétés répétés ne sont pas interprétés uniformément par tous les parseurs.
| Entrée de démonstration | Lecture syntaxique | Contrôle restant |
|---|---|---|
| {"ok":true} | Valide. | La valeur respecte-t-elle le contrat ? |
| {"ok":true,} | Invalide : virgule finale. | Gérer explicitement l’erreur. |
| null | Valide. | Le contrat autorise-t-il une valeur nulle ? |
| {"id":9007199254740993} | Nombre valide, précision risquée en JavaScript. | Prévoir une chaîne pour cet identifiant. |
| {"a":1,"a":2} | Noms répétés : interprétation non portable. | Définir et appliquer une politique de rejet. |
Contrôler chaque étape de réception
- Utilisez un parseur JSON maintenu, jamais eval. Vérifiez statut HTTP, type de contenu attendu, limite de taille et gestion explicite d’un corps absent ou malformé.
- Validez ensuite le contrat : type racine, champs requis, valeurs permises et différence entre absence, null et zéro. Conservez les identifiants longs comme chaînes si le contrat le prévoit.
- Fixez limites de profondeur et de ressources, politique sur les noms répétés et traitement des erreurs. N’insérez pas une chaîne reçue comme HTML ou requête sans protection adaptée.
Conserver des erreurs utiles sans exposer les données
Testez réponses partielles, changements de version et caractères Unicode. Journalisez un contexte minimal plutôt que secrets ou corps complets. Une erreur de décodage ne doit ni devenir un résultat vide présenté comme succès, ni interrompre silencieusement toute une chaîne de traitement.
Références primaires
API JSON : journaliser sans divulguer les charges
Un corps JSON peut contenir identifiants, secrets ou données personnelles. Pour diagnostiquer une erreur ou une attaque, conserver surtout type d’événement, route, résultat, identifiant de corrélation et détail d’échec non sensible.
- Classer les champs et masquer ceux qui ne sont pas nécessaires au diagnostic.
- Tester les erreurs de parsing et de schéma avec des valeurs fictives.
- Vérifier que les traces d’erreur et les exports ne reproduisent pas la charge complète.
Référence primaire : ACSC and partners — Event logging and threat detection. Méthode connexe : consulter le guide pratique.
Le cache doit distinguer les représentations JSON
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Deux versions d’une route renvoient des schémas différents ; le client reçoit une réponse mise en cache pour une autre version.
- Tester la sélection de version et les dimensions qui déterminent la représentation, puis comparer les clés du cache et les validations du client.
- Séparer les représentations et traiter explicitement les incompatibilités. Une réponse JSON analysable peut rester incompatible avec le contrat attendu.
Référence primaire : IETF — RFC 9111, HTTP Caching. Méthode connexe : consulter le guide pratique.
Valider aussi les champs de continuation
Le parsing d’une réponse paginée doit préserver les identifiants et les informations de continuation. Un JSON lisible peut contenir une page courte ou un jeton inattendu ; vérifiez ces états selon le contrat avant de conclure que la collection est terminée.
- Tester page courte avec continuation et réponse sans jeton de fin attendu.
- Conserver types et valeurs des identifiants sans conversion qui les altère.
- Détecter jeton répété, réponse tronquée et reprise après conservation du lot.
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}Décision attendue
B est répété. Contrôler les identifiants et continuer tant qu’un curseur suivant existe, même après une page vide.
Procédure de vérification
- Fixez filtres, ordre stable et identité des objets.
- Testez doublon et page vide avec curseur suivant.
- Conservez identifiants, curseurs et condition de fin réelle. Rapprochez objets reçus et identifiants uniques ; signalez un curseur répété sans transformer une page vide avec suite en fin de collecte.
Référence primaire : Google AIP-158 — Pagination. Méthode connexe : consulter le guide pratique.