X-XSS-Protection est un en-tête HTTP qui active le filtrage XSS intégré dans certains navigateurs. Alors que les navigateurs modernes s'appuient davantage sur la politique de sécurité du contenu, cet en-tête offre une couche de protection supplémentaire pour les navigateurs plus anciens. Il peut être configuré pour bloquer ou nettoyer les tentatives XSS détectées.
X-XSS-Protection est un en-tête de réponse hérité qui contrôlait l'auditeur XSS intégré autrefois livré avec Internet Explorer, Edge et les navigateurs Chromium. Ses valeurs allaient de 0 (désactiver le filtre), à 1 (activer et assainir le contenu signalé), jusqu'à 1; mode=block (activer et bloquer toute la page en cas de détection). Le filtre tentait de repérer les scripts réfléchis, du code apparaissant à la fois dans la requête et la réponse, et de le neutraliser avant son exécution. Les navigateurs modernes ont entièrement supprimé ce filtre : Chrome, Edge et Safari ne réagissent plus à l'en-tête, et il n'a jamais existé dans Firefox. Il est désormais considéré comme obsolète, supplanté par la Content Security Policy.
L'en-tête comptait historiquement parce qu'il offrait une certaine atténuation du XSS réfléchi aux navigateurs antérieurs à une Content Security Policy mature. En pratique, les filtres se sont révélés peu fiables et, pire encore, ont introduit leurs propres vulnérabilités : le mode d'assainissement pouvait être détourné pour désactiver sélectivement des scripts légitimes, et des chercheurs ont découvert des canaux annexes de fuite d'information et de XSS universel créés par l'auditeur lui-même. C'est pourquoi les éditeurs l'ont déprécié puis supprimé. Aujourd'hui, envoyer 1; mode=block est au mieux inerte et au pire réactive un comportement bogué dans un ancien navigateur. Les recommandations actuelles préconisent soit d'omettre l'en-tête, soit d'envoyer explicitement 0, et de s'appuyer plutôt sur une CSP robuste et l'encodage de sortie.
Ne comptez pas sur X-XSS-Protection. Réglez-le sur 0 ou laissez-le désactivé, et concentrez vos efforts sur les contrôles qui arrêtent réellement le XSS aujourd'hui : l'encodage de sortie sensible au contexte, la validation des entrées, l'assainissement du DOM pour tout HTML que vous insérez, les cookies HttpOnly pour que les jetons volés soient plus difficiles à atteindre, et une Content Security Policy stricte fondée sur un nonce. Lorsque le risque de XSS provient de JavaScript tiers ou injecté plutôt que de vos propres templates, cside ajoute une couche complémentaire en faisant transiter les scripts tiers par un méthode Script, en analysant la charge utile et en bloquant les comportements malveillants en temps réel tout en conservant une trace forensique, autant d'éléments que l'en-tête déprécié n'a jamais fournis.
Aucun navigateur actuel n'y réagit ; Chrome, Edge et Safari ont supprimé le filtre et Firefox ne l'a jamais eu. La plupart des recommandations préconisent d'omettre l'en-tête ou d'envoyer 0, puis de s'appuyer sur une Content Security Policy robuste et l'encodage de sortie. Envoyer 1; mode=block ne fait rien d'utile et peut déclencher un comportement ancien et bogué.
Les auditeurs n'attrapaient que du XSS réfléchi simple tout en créant à répétition de nouveaux problèmes, notamment des moyens de désactiver des scripts précis et des bogues de cross-site-scripting universel ou de fuite d'information. Les corriger de manière fiable s'est révélé impraticable, et la Content Security Policy offrait une alternative bien plus robuste et normalisée, si bien que les éditeurs ont choisi de supprimer entièrement le filtre.
We answer client-side security questions every day. Bring yours.