CSP allows broad script or object sources

Why it matters

web.dev's guide to a strict script policy explains that host lists can be bypassed in many configurations and recommends nonces or hashes with 'strict-dynamic'. A broad source token in script-src or object-src is worth reviewing in that policy, even though another enforcing policy may narrow the browser's effective permission.

What to do

Look at the finding: it shows the policy, the broad sources found for scripts or objects and up to ten pages that send it.
Replace them with the hosts you actually load scripts from, set object-src 'none' if you use no plugins, or move scripts to nonces or hashes with 'strict-dynamic'.
Remove *, http:, https: and data: from script-src and object-src, or from default-src where those directives are absent.

When to leave it as it is: if the broad source is a fallback beside 'strict-dynamic' and a nonce or hash, you can leave it: browsers that support 'strict-dynamic' ignore it, although the check still reports it.

What we read

We read the enforcing policies of each crawled page with our own user agent: each policy in a Content-Security-Policy response header, and a CSP <meta> tag inside <head>. Report-only headers are not read. Each policy is judged on its own, as it is written, not combined with the page's other policies the way a browser applies them.

In a policy we take script-src and object-src, each falling back to default-src when absent. The policy is reported when either contains *, http:, https: or data:, in any letter case. Host patterns such as *.example.com, blob: and other directives such as style-src or img-src are not reported.

Pages that send the same policy text are reported together, one finding per exact text; a policy that carries a new nonce on every response gives each page a finding of its own. Pages whose headers or HTML were not captured in full are not judged.

Example & evidence

Illustrative example — one policy, not a live audit.

https://bakery.example/ sends:

Content-Security-Policy: script-src 'self' https:; object-src *

This policy lists all https: script sources and * for objects, so the check reports both broad tokens. Another enforcing policy could narrow what actually loads.

Content-Security-Policy: script-src 'self' https://cdn.bakery.example; object-src 'none'

A possible correction: name the one host scripts come from and switch plugins off.

Confirm & check again

Check for yourself: open the page's response headers and read script-src, object-src and default-src in Content-Security-Policy for a bare *, http:, https: or data:.

Check again: Full audit — run a new full audit. With complete coverage, this policy-text finding closes only when no currently crawled page sends the same flagged policy text; a new page using the old text keeps it open. Changed text is evaluated as a new policy text and may create another finding if a broad source remains.

Limits & sources

Each policy is judged alone, and a broad source is reported even beside 'strict-dynamic', where supporting browsers ignore it. The check reads the declaration only and does not see which scripts load.

Confidence: High because the policy text is read directly.

Sources

web.dev, Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP) — explains that policies built on lists of hosts can be bypassed in most configurations and recommends nonces or hashes with strict-dynamic, noting that supporting browsers then ignore an https: fallback. Checked 28 September 2026.

Editorial review: 2 November 2026

A script policy declares unsafe-inline without a nonce, hash or strict-dynamic — one policy contains an effective unsafe-inline token for scripts.
A Content Security Policy lacks object or base-address restrictions — the policy says nothing about plugin objects or the page's base address.

A Content Security Policy lists broad script or object sources