CSP uses an overly broad script source
ShipReady found either a universal wildcard or a bare scheme source in the effective script policy.
Why it matters
A universal wildcard or an unrestricted scheme can allow scripts from a broader set of locations than an application intended. The policy evidence should be reviewed in the context of the application's approved script origins; it does not prove that an untrusted script has run.
How ShipReady detects it
What it inspects
ShipReady parses the enforcing Content-Security-Policy header and inspects effective script sources: script-src when present, otherwise the default-src fallback.
What triggers a finding
The rule triggers when an effective script source is the universal wildcard or a bare scheme token such as https:, http:, data:, or blob:.
What the evidence shows
The report identifies whether the observed source value came from script-src or the default-src fallback and records the parsed script-source value containing the broad source.
Limits of this check
ShipReady does not flag scoped host wildcards or full host sources through this rule, inspect other CSP directives, load scripts, or analyze a separate Report-Only policy. It does not determine whether a permitted source is malicious or prove that a script can be abused.
How to fix it
Enumerate required script origins
Replace the broad source with the smallest set of specific origins and source expressions needed for application and third-party scripts.
Test integrations after tightening the policy
Exercise pages that load first-party and approved third-party scripts, then remove sources that are no longer required.
How to verify the change
Verify the deployed script policy
Inspect the enforcing Content-Security-Policy header and determine the effective script sources, including default-src fallback when script-src is absent.
Expected: The effective script policy uses only the intended specific sources and does not retain an unnecessary universal wildcard or bare scheme.