Security headers · Check
CSP uses bare * — replacing wildcards with explicit allowlists
At least one CSP directive uses a bare `*` source. That permits any host on the Internet to supply the resource type — defeating the directive's purpose of restricting where content may load from.
Why it matters
Replace `*` with explicit hostnames (`https://cdn.example.com`) or scheme-restricted subdomain wildcards (`https://*.example.com`). Bare `*` is rarely necessary outside of `img-src`, and even there it's worth the audit.
Real-world risk
A bare * in any directive lets an attacker load resources from any origin on the Internet — defeating the directive's purpose.
Fix steps (in order)
- Replace * with explicit hostnames you control or trust (https://cdn.example.com).
- Use scheme-restricted subdomain wildcards (https://*.example.com) instead of bare * if you need flexibility.
- Audit each directive separately; img-src is sometimes intentionally wide, but script-src and connect-src should never be *.
Topic explainer
What is Content Security Policy (CSP)? A practical explainer →
An accessible explanation of Content Security Policy: what it does, why it exists, the directives that matter, and how to roll one out without breaking your app.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (csp_wildcard_source) clears once the externally-observable signal is in place.