Description
What is missing or needs to be updated?
Some security headers such as Content-Security-Policy are (as far as I can tell) relevant on all HTML pages, including error pages. But the recommended configuration for Apache or nginx only sets headers on successful responses (2xx or 3xx).
See the Apache docs on Header set:
The optional condition argument determines which internal table of responses headers this directive will operate against: onsuccess (default, can be omitted) or always. The difference between the two lists is that the headers contained in the latter are added to the response even on error, and persisted across internal redirects (for example, ErrorDocument handlers). [...]
And the nginx docs on add_header:
Adds the specified field to a response header provided that the response code equals 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307 (1.1.16, 1.0.13), or 308 (1.13.0). Parameter value can contain variables. [...]
If the always parameter is specified (1.7.5), the header field will be added regardless of the response code.
Example of how that could be problematic: A site that shows user generated content has an XSS vulnerability in their app code, but it doesn't take effect because the server admin configured a strong CSP using the recommended Apache/nginx configuration. However, the CSP is not sent on 404 pages. If the app adds a feature to show content on 404 pages (ie. "What you're looking for doesn't exist, but check out this instead"), the XSS vulnerability could now be exploited.
How should this be resolved?
Add always to the recommended configuration for Apache and nginx, or add an explanation that the default is to only set headers on success responses.
Apache:
<IfModule mod_headers.c>
Header always set X-Frame-Options "DENY"
</IfModule>
nginx:
add_header "X-Frame-Options" "DENY" always;