05. Champs, valeurs et frontières d’interprétation

Comprendre le mécanisme

Les champs HTTP transportent des métadonnées avec une syntaxe et une sémantique définies par champ. Certains acceptent des listes ; d’autres ne peuvent pas être combinés arbitrairement. Une application ne doit pas supposer que toutes les valeurs multiples se concatènent avec une virgule. Les noms de champs sont insensibles à la casse, mais les valeurs obéissent à leurs règles propres. Les intermédiaires peuvent aussi supprimer ou reconstruire des informations sur chaque saut.

Raisonner et vérifier

Une valeur reçue du client demeure non fiable, même lorsqu’elle porte un nom évoquant la sécurité. Évitez de construire un champ de réponse en concaténant des entrées contenant des caractères de contrôle. Utilisez les API structurées du framework et une liste fermée pour les choix de politique. Testez les doublons, valeurs absentes, casse et normalisations avec le véritable chemin proxy-application, en observant ce que chaque couche transmet.

Casse des noms

Les noms de champs sont insensibles à la casse. La casse du nom ne change pas sa sémantique HTTP. Content-Type et content-type désignent le même nom de champ. Utilisez les API du serveur et du client pour éviter une logique de sécurité qui ne vérifierait qu’une orthographe particulière.

Valeurs spécifiques

Les règles des valeurs dépendent du champ. La grammaire des valeurs est propre au champ. Un nom insensible à la casse n’implique pas une règle uniforme sur toutes les valeurs. Suivez la définition de chaque champ avant de normaliser, découper ou comparer ses données.

Champs multiples

Certains champs ne se combinent pas librement. La combinaison dépend de la définition du champ. Set-Cookie doit conserver ses valeurs selon ses règles propres. Une fusion générale par virgule peut modifier l’interprétation ; testez le résultat à travers les bibliothèques et proxies réellement utilisés.

Négociation

Accept exprime une préférence de représentation. Content-Type décrit le contenu du message concerné. Accept décrit les préférences du client sur la représentation reçue. Content-Type décrit le type du contenu envoyé ; inverser ces rôles peut produire un parsing erroné ou une réponse inattendue.

Rôle client hostile

Un champ de rôle client reste non fiable. Le nom ne prouve pas l’autorité du producteur. X-User-Role: admin n’établit pas un privilège. Une architecture de headers d’identité exige un intermédiaire authentifié qui retire les valeurs externes et une application qui ne fait confiance qu’à ce chemin.

API structurée

Les API structurées évitent des concaténations dangereuses. Des caractères de contrôle peuvent altérer l’interprétation. Ne concaténez pas une entrée contenant retours de ligne dans une réponse HTTP brute. Utilisez les APIs de champs et leurs validations, puis testez les valeurs malformées avant toute émission.

Transformation proxy

Un proxy peut reconstruire certains champs. Les intermédiaires peuvent transformer le message. Un proxy peut supprimer, ajouter ou réécrire des champs. Définissez lesquels font autorité et observez les deux côtés ; l’application ne voit pas nécessairement les mêmes octets que le navigateur.

Trajet réel

Il faut tester les champs multiples sur le trajet réel. Les parseurs successifs peuvent appliquer des traitements différents. Des champs dupliqués peuvent être conservés ou regroupés différemment selon les composants. Une fixture unitaire ne prouve pas le comportement complet ; testez dans un environnement isolé qui reproduit la chaîne.

Nom flatteur

Un identifiant client ne devient pas fiable par renommage. Une convention de nommage n’établit pas une confiance. Renommer une valeur client en Trusted-User ne change pas sa provenance. La confiance dépend de l’authentification du producteur et du contrôle du trajet, pas du vocabulaire choisi dans le nom.

Absence prévue

Une absence peut demander un refus ou une valeur prévue. La politique doit définir les cas manquants. Définissez si un champ requis absent provoque un refus ou un défaut sûr. Une valeur de repli trop permissive peut ouvrir un accès lorsque le proxy ou un client omet une donnée nécessaire.

Atelier guidé : lire, expliquer et vérifier le code

Set-Cookie: lab_session=a; Path=/; HttpOnly
Set-Cookie: lab_theme=dark; Path=/

Les deux lignes Set-Cookie décrivent deux cookies distincts. Elles ne doivent pas être transformées mécaniquement en un champ fusionné comme n’importe quelle liste. Vérifiez le nombre de cookies effectivement reçus par le navigateur et gardez leur attribut Path et leur protection individuelle.

La combinaison des champs dépend de leur définition, pas d’une règle universelle. Les grammaires et règles de combinaison diffèrent. Un séparateur n’est pas un chiffrement. Plusieurs champs Set-Cookie peuvent être nécessaires.

Travail pratique : Inventoriez les champs utilisés pour langue, format, identité et corrélation. Pour chacun, définissez producteur autorisé, validation et comportement en cas de doublon.

Critères de correction : Envoyez des requêtes de laboratoire avec variantes contrôlées et relevez la valeur effectivement lue par le framework. Refusez les ambiguïtés pertinentes au lieu de laisser deux couches interpréter des identités différentes.