Deprecated X-XSS-Protection, the Old Security Header That Should Be Off
Deprecated X-XSS-Protection enabled. That is the flag when a site sends an old security header with a value that turns a legacy browser feature on. It is the rare finding where the fix is to switch something off rather than on, and it is also one where the name sounds more alarming than the reality. This header is not doing what it once promised, and keeping it enabled can do more harm than good.
Put the finding in context. X-XSS-Protection was an early attempt by browsers to block reflected cross-site scripting, and it is now deprecated, which means the browsers that mattered have removed or ignored it. Sending it with an enabling value is not a vulnerability on its own, which is why this finding is advisory and low severity. What it signals is a server running an outdated security setting that the modern defence has replaced.
Why the header was retired
The header asked the browser to run a built-in filter that tried to detect and block reflected cross-site scripting attacks. The filter sounded useful, but it had a known weakness, in some cases its own detection could be tricked, and the filtering it applied introduced problems of its own. Browsers gradually removed the feature, and the header now does little in the browsers people actually use.
The modern replacement is a Content-Security-Policy. A proper policy tells the browser exactly which sources of script are allowed, which prevents injected script from running in the first place, rather than trying to detect an attack after it happens. That is the architectural difference, the old header played whack-a-mole with attacks, the modern policy removes the molehill.
What this finding does and does not mean
This finding is advisory, and the report says so plainly. It costs no points directly, because it is not a deduction and not a missing credit, it is a note that a setting is outdated. The engine flags it when the header is set to an enabling value, usually the value 1 with mode=block, and the fix is to set it to 0 instead, which is the explicit way to say the legacy filter should stay off.
The real point of the finding is what it points toward. An X-XSS-Protection header set to an enabling value usually means the server has an old security-headers config that predates modern practice, and the same config often lacks the headers that actually matter. Fixing this one header is a small step, and the valuable step is checking whether a Content-Security-Policy is in place, because that is the defence this header was meant to replace.
Switching X-XSS-Protection off
The fix is one header line, and the value matters. Setting X-XSS-Protection to 0 tells browsers the legacy filter should stay off, which is the recommended state, because the filter is deprecated and its protection is gone. Some guides suggest removing the header entirely, and that also works, but setting it to 0 is the deliberate choice that says the removal is intentional rather than accidental.
On Apache or LiteSpeed, the header lives in the virtual host or an .htaccess file, and on nginx it goes in the server block. If a Content-Security-Policy is already in place, the site is properly defended and the header can come off with no loss, if one is missing, that is the real work, and the missing Content-Security-Policy guide covers building one.
# Apache / LiteSpeed Header always set X-XSS-Protection "0" # nginx add_header X-XSS-Protection "0" always;
If the header was added by a security plugin or a hosting panel setting, look for the option that controls it and set it to off or disabled rather than editing config that a plugin may overwrite. On nginx there is one trap worth naming, if any location block declares its own add_header, the header from the server block is silently dropped for requests that match that location, so the line has to be repeated inside those location blocks too. The same rule applies as with every header change, after making it, confirm the new value actually reaches the visitor, because a cached copy or a CDN rule can keep serving the old header.
Behind a CDN, check the edge, because that is often where the header comes from. Our own two sites are the working example. Both origins are clean, neither nginx setup sends the header, yet one site serves X-XSS-Protection 0 through the edge while the other serves the deprecated 1 with mode=block, because a header rule at the CDN differs between them. The finding fires on the site with the enabling value, which shows why the check reads what the visitor receives, not what the origin intends.
Confirming the switch, then the real work
Run another Enterramon test after the change and the finding clears, because the report reads the header the visitor receives. The change is easy to verify, the header now reads 0 or is gone entirely, and the flag disappears with it. Since the finding is advisory, the cleared flag is not a score change, it is a confirmation that the outdated setting is gone.
Then do the part that matters. If the report also flagged a missing Content-Security-Policy, fixing that one is the actual security work, because the policy is what replaces the retired filter. The X-XSS-Protection header is a legacy switch, and flipping it off is the cleanup, while a real Content-Security-Policy is the defence the cleanup makes room for.
