What legacy security headers are

How it works

Security headers come and go. Some were replaced by better ones, others removed from browsers because they caused more problems than they solved. Old configurations, templates and tutorials still carry them. The main ones:

• X-XSS-Protection switched on a filter meant to detect injected scripts. The filter could itself be exploited, for instance to switch off parts of a page on purpose or to spy on content. All major browsers have removed it; Firefox never had one. The Content Security Policy takes over the protection.
• Public-Key-Pins and Public-Key-Pins-Report-Only (HPKP) fixed which keys a site may use. One mistake and the site was locked for all visitors for the configured duration. Browsers no longer read the header.
• Expect-CT demanded that certificates appear in public logs (Certificate Transparency). The major browsers now require that on their own, so the header is redundant.

Two more leftovers have articles of their own: X-Frame-Options: ALLOW-FROM under clickjacking protection and Feature-Policy under the Permissions-Policy.

What matters

• Don't switch on X-XSS-Protection. Values like 1 or 1; mode=block are a risk in old browsers that still have the filter. Only 0 or no header at all is harmless.
• Remove pinning and Expect-CT. They no longer work, but they clutter the configuration and suggest protection that isn't there.
• Put the replacement in place. If you remove X-XSS-Protection, you should have a Content Security Policy.

How to clean up

Search the web server configuration, .htaccess, your CDN settings and any CMS security plugins for the header names and delete those lines. If you would rather switch X-XSS-Protection off explicitly, send:

X-XSS-Protection: 0

In nginx, remove the matching add_header lines; in Apache, the Header set lines. If a header comes from a plugin or the hosting provider, switch it off there or ask your agency.