The policy allows resources from anywhere

Updated 2026-10-12

LowConfirmedweb.security-headers.csp-wildcard-source

50% of the 360 domains we could check get a warning for this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured

What this check looks for

Part of the policy uses a wildcard, which permits any site at all. For that kind of resource the policy restricts nothing.

Why it matters

A policy is only as strong as its loosest directive. A wildcard in one place often makes the careful work done everywhere else irrelevant.

When the check passes, your report says: “Every source in the policy names a specific origin”.

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.csp family ceiling of 30 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: low
Default confidence: confirmed
Status when triggered: warn
Deduction: 6 points
Family cap: web-security.csp · 30
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

Replace each wildcard with the specific origins the page actually uses.

One wildcard directive can undo the whole policy.

Use report-only mode to collect the origins the page really loads from.
List those origins explicitly.
For scripts, prefer a nonce with 'strict-dynamic' — it removes the allow-list entirely.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i content-security-policy

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'; img-src 'self' data:; object-src 'none'; base-uri 'none'" always;

Apache

<IfModule mod_headers.c>
	Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'none'"
</IfModule>

Caddy

header {
	Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'none'"
}

Cloudflare

Rules → Overview → Create rule → Response Header Transform Rule → Set static → Content-Security-Policy = default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'none'
(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

These directives allow a source that matches practically anything: ‹directives›.

What counts is read per directive. *, a bare https: or http:, and a host wildcard over a whole public suffix such as *.com match every site on the web, so they count wherever they appear. data:, blob: and filesystem: fetch nothing from anywhere — the content is in the URL or was built by the page — so they count only where the directive governs code: in script-src or object-src, or default-src when scripts or plugins fall back to it, an injection can carry its whole payload as a data: URL, and a script list that allows it also fails csp-missing. In img-src or font-src, data: is an inline image or font and is not reported. A wildcard in img-src is a much smaller matter than one in script-src, and the report names each directive so the difference is visible. Behind 'strict-dynamic' with a nonce, the host and scheme sources in script-src are ignored by the browser, and are not reported.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the web security headers checker Build the fix