X-XSS-Protection is een HTTP-header die ingebouwde XSS-filtering inschakelt in sommige browsers. Hoewel moderne browsers meer vertrouwen op Content Security Policy, biedt deze header een extra beschermingslaag voor oudere browsers. Het kan worden geconfigureerd om gedetecteerde XSS-pogingen te blokkeren of te saneren.
X-XSS-Protection is een verouderde responseheader die de ingebouwde XSS-auditor aanstuurde die ooit in Internet Explorer, Edge en Chromium-browsers zat. De waarden liepen uiteen van 0 (schakel het filter uit), via 1 (inschakelen en gemarkeerde content saneren), tot 1; mode=block (inschakelen en de hele pagina blokkeren bij detectie). Het filter probeerde reflected scripts te herkennen, code die zowel in het verzoek als in de response voorkomt, en die onschadelijk te maken voordat ze werd uitgevoerd. Moderne browsers hebben dit filter volledig verwijderd: Chrome, Edge en Safari reageren niet meer op de header, en in Firefox heeft die nooit bestaan. Hij wordt nu als achterhaald beschouwd, vervangen door Content Security Policy.
De header deed er historisch toe omdat hij enige reflected-XSS-mitigatie bood voor browsers die dateerden van vóór een volwassen Content Security Policy. In de praktijk bleken de filters onbetrouwbaar en, erger nog, introduceerden ze hun eigen kwetsbaarheden: de sanitize-modus kon worden misbruikt om legitieme scripts selectief uit te schakelen, en onderzoekers vonden information-leak- en universele-XSS-zijkanalen die door de auditor zelf werden gecreëerd. Daarom hebben leveranciers hem afgeschaft en verwijderd. Vandaag de dag is het versturen van 1; mode=block op zijn best inert en op zijn slechtst een heractivering van buggy gedrag in een oude browser. De huidige richtlijn raadt aan de header ofwel weg te laten, ofwel expliciet 0 te versturen, en in plaats daarvan te leunen op een sterke CSP en output-encoding.
Vertrouw niet op X-XSS-Protection. Zet hem op 0 of laat hem weg, en steek je energie in de controls die XSS vandaag de dag daadwerkelijk stoppen: contextbewuste output-encoding, invoervalidatie, DOM-sanitization voor alle HTML die je invoegt, HttpOnly-cookies zodat gestolen tokens moeilijker te bereiken zijn, en een strikte, nonce-gebaseerde Content Security Policy. Waar XSS-risico voortkomt uit third-party of geïnjecteerd JavaScript in plaats van uit je eigen templates, voegt cside een aanvullende laag toe door third-party scripts via een Script-methode te routeren, de payload te analyseren en kwaadaardig gedrag in realtime te blokkeren terwijl het een forensische registratie bijhoudt, niets waarvan de afgeschafte header ooit voorzag.
Geen enkele huidige browser reageert erop; Chrome, Edge en Safari hebben het filter verwijderd en Firefox heeft het nooit gehad. De meeste richtlijnen raden aan de header weg te laten of 0 te versturen, en vervolgens te leunen op een sterke Content Security Policy en output-encoding. Het versturen van 1; mode=block doet niets nuttigs en kan oud, buggy gedrag uitlokken.
De auditors vingen alleen eenvoudige reflected XSS af terwijl ze telkens nieuwe problemen creëerden, waaronder manieren om specifieke scripts uit te schakelen en universele cross-site-scripting- of information-leak-bugs. Ze betrouwbaar repareren bleek onhaalbaar, en Content Security Policy bood een veel sterker, gestandaardiseerd alternatief, dus leveranciers kozen ervoor het filter helemaal te verwijderen.
We answer client-side security questions every day. Bring yours.