Limiter la réécriture de contenu par le proxy avec no-transform et HTTPS

Un proxy qui transforme le contenu peut modifier une réponse sur le chemin du navigateur : recompresser une image, réécrire le balisage ou insérer un JavaScript d'appui. Une page qui fonctionne sur un réseau et reçoit un balisage inconnu sur un autre peut rencontrer précisément ce comportement d'intermédiaire.

Pour un site que vous exploitez, HTTP fournit une directive de réponse explicite :

Cache-Control: no-transform

La RFC 9111 exige qu'un intermédiaire recevant cette directive de réponse laisse le contenu non transformé, qu'il implémente ou non un cache. Cela concerne la recompression d'images et l'injection de balisage, pas seulement le fait qu'un objet soit stocké.

Conservez-la avec la politique de cache existante

Si une réponse possède déjà des directives de cache, ajoutez l'exigence délibérément au lieu d'écarter le reste de la politique. Par exemple, une ressource publiquement cachable pourrait avoir :

Cache-Control: public, max-age=3600, no-transform

Cet exemple conserve une politique de fraîcheur d'une heure tout en interdisant la transformation du contenu. no-transform n'implique pas no-store et ne désactive pas le traitement ordinaire du transfert. Définissez-la sur les réponses dont le contenu d'origine importe, y compris les réponses d'image séparées le cas échéant.

La directive agit par le respect de l'intermédiaire. Elle n'empêche pas cryptographiquement un équipement réseau d'ignorer l'instruction.

Protégez aussi le transport

HTTPS donne au navigateur une connexion avec authentification et protection de l'intégrité vers son pair TLS. Un proxy d'opérateur ordinaire qui laisse passer du trafic chiffré ne peut pas insérer silencieusement un script dans cette connexion protégée. Maintenez la vérification des certificats ; un proxy d'inspection de confiance local qui termine TLS est un autre dispositif.

Servez la page et ses ressources dépendantes en HTTPS. Redirigez les visiteurs HTTP vers HTTPS et envisagez HSTS pour un déploiement qui peut le prendre en charge de façon constante. Une simple redirection commence par un échange HTTP non protégé pour un visiteur ayant utilisé une URL HTTP ; une politique HSTS apprise auparavant ou préchargée change ce choix initial.

Bloquer un script injecté peut réduire ses effets visibles, mais la réponse peut déjà contenir du HTML modifié ou des URL d'images réécrites. Remplacer un ancien nom de fonction, ajouter un commentaire inhabituel ou mapper une adresse d'injection historique n'établit pas l'intégrité du contenu pour l'intermédiaire suivant.

Lors de l'examen d'un signalement, comparez la réponse reçue au contenu prévu de l'origine et identifiez où TLS se termine. Cette preuve est plus utile que de traiter chaque script inconnu comme un défaut dans le code applicatif du site lui-même.