Set Apache security headers correctly

The fixconf-available/security-headers.conf

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Content-Security-Policy "frame-ancestors 'self'"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

sudo a2enmod headers
sudo a2enconf security-headers
sudo apachectl -t && sudo systemctl reload apache2

Read the HSTS warning in the safety section before deploying that last line.

always is not optional

Without always, Header set writes to Apache’s onsuccess table, which applies only to successful responses. Your 404s and 500s ship no security headers at all.

Header set X-Content-Type-Options "nosniff"          # not on error pages
Header always set X-Content-Type-Options "nosniff"   # on everything

Error pages are where reflected content and stack traces show up, so they are precisely where nosniff and a frame policy matter. Use always on every security header, every time. There is no downside.

Apache does not have nginx’s inheritance trap

Worth stating plainly, because it’s the first thing anyone arriving from nginx will worry about.

In nginx, a single add_header in a location block silently discards every inherited header. Apache’s mod_headers does not work that way: directives from the server config, the vhost, and <Directory> sections accumulate. Adding a header in a subdirectory does not delete the ones set above it.

So the nginx failure mode — one path quietly serving no security headers — does not happen here. That’s a genuine point in Apache’s favour and one less thing to audit.

The trap Apache has instead is Header unset and Header set on the same name: later directives can replace earlier values, and the processing order (server → vhost → directory → .htaccess) means a .htaccess can override your carefully set header — which is one more reason for AllowOverride None.

Do not set X-XSS-Protection

Every Apache hardening guide still recommends this:

Header always set X-XSS-Protection "1; mode=block"    # don't

It is deprecated, and not harmlessly. The header enabled a browser XSS filter that researchers showed could be turned against the page it was protecting: a crafted URL could make the filter misidentify a legitimate script as an attack and selectively disable it — letting an attacker switch off a page’s own security scripts. MDN states it “can create XSS vulnerabilities in otherwise safe websites”.

Browsers removed the filter. The header does nothing current and it is a documented footgun. Delete the line; a real Content-Security-Policy is the replacement.

X-Frame-Options is superseded

frame-ancestors in CSP is the standard and is strictly more capable — it takes a source list rather than one origin, and covers <frame>, <iframe>, <embed> and <object>.

Keeping X-Frame-Options: SAMEORIGIN alongside is harmless for old browsers. Just don’t set it instead, and don’t let the two disagree — frame-ancestors wins where it’s supported, which will confuse whoever debugs it later.

Verify it worked

Check what’s actually sent, from outside:

curl -sI https://your.site/ | grep -iE 'content-type-options|referrer-policy|content-security-policy|strict-transport|x-xss'

Then check an error response, which is what always is for:

curl -sI https://your.site/definitely-not-real | grep -ic 'x-content-type-options'

0 means you forgot always — that’s the whole test, and the config file won’t tell you.

Confirm the module is loaded:

sudo apachectl -M 2>/dev/null | grep headers_module

Find any lingering X-XSS-Protection:

sudo grep -rn 'X-XSS-Protection' /etc/apache2/ /etc/httpd/ /var/www 2>/dev/null

Every result should be deleted.

For an external grade, securityheaders.com reports the whole set in one request.

Before you apply this

HSTS is the one that is hard to undo. max-age=63072000; includeSubDomains tells browsers to refuse plaintext for your host and every subdomain for two years, and setting it back to max-age=0 only reaches people who visit again.

Before deploying that line:

1. Start with max-age=300. Five minutes of commitment.
2. Confirm every subdomain serves HTTPS before adding includeSubDomains — including ones you don’t manage. A subdomain that only speaks HTTP becomes unreachable in every browser that has seen your main site, with no click-through and no way to fix it from that subdomain’s side.
3. Raise max-age only once you’re sure.

Do not add preload casually — removal takes months of browser releases. The full reasoning is on the nginx HSTS page and applies identically.

frame-ancestors 'self' breaks intentional embedding. If a partner, a status page or your own admin tool iframes your site, it stops with a blank frame and a console error. Name the origins if you need them: frame-ancestors 'self' https://partner.example.

A full CSP is a project, not a line. frame-ancestors is safe because it only governs framing. Adding default-src 'self' to an existing site breaks inline scripts, analytics and third-party widgets immediately. Deploy with Content-Security-Policy-Report-Only first, collect violations, then enforce.

Related

• Configure Apache TLS — HSTS assumes this works.
• Disable .htaccess — stops a directory overriding your headers.