A security header was sent twice with different values

MediumConfirmedQuick winweb.security-headers.duplicate-conflicting

What this check looks for

The same header arrived more than once with conflicting values. Which one applies depends on the browser, so the protection you think you have may not be the one in force.

Why it matters

Two different Content-Security-Policy headers do not combine into a stronger one — browsers enforce both, which means the intersection, and that is almost never what either author intended. Two different HSTS headers are simply ambiguous.

When the check passes, your report says: “Each security header arrived once, with one value”.

What it costs your score

When this check fails it removes 6 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.headers family ceiling of 20 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: warn
Deduction: 6 points
Family cap: web-security.headers · 20
Category: Web security
Module: Web security headers
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Set each security header in exactly one place.

Two conflicting values mean the policy actually in force is not the one you wrote.

Find both sources: check the application, the web server, and any proxy or CDN in front.
Keep the one closest to the application, and remove the other.
Re-test and confirm the header now appears once.

How to confirm it worked

curl -sSI https://‹host›/ | grep -ci '^content-security-policy:' — expect 1

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

add_header Content-Security-Policy "default-src 'self'" always;

Apache

<IfModule mod_headers.c>
	Header always set Content-Security-Policy "default-src 'self'"
</IfModule>

Caddy

header {
	Content-Security-Policy "default-src 'self'"
}

Cloudflare

Rules → Overview → Create rule → Response Header Transform Rule → Set static → Content-Security-Policy = default-src 'self'
(Dashboard path as at 2026-09; Cloudflare reorganised these pages and may again.)

The always flag matters: without it nginx omits the header on error responses, which are exactly the ones an attacker aims for. Note also that any add_header in a location block discards every add_header inherited from the server block.
Shown because the response identified Apache. Put it in the virtual host rather than .htaccess: .htaccess is re-read on every request, and Header always set there runs too late for responses the server generates itself.
A Transform Rule adds the header at Cloudflare's edge, so it applies only to responses that reach visitors through Cloudflare. An origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the response measured here without it. Setting it at the origin covers both paths.

Technical detail

‹detail›

This usually happens when a header is set in two places: an application framework and a web server, or a server block and a location block, or an origin and a CDN. Set each security header in exactly one place. In nginx, note that an add_header in a location block discards every add_header from the enclosing server block rather than adding to it, which produces the opposite of this problem and is worth checking at the same time.