Missing or Wildcard CSP script-src Directive

What's wrong

The Content Security Policy does not restrict script execution. This occurs in three patterns. First: the CSP has no script-src directive and default-src is either absent or set to a value that permits broad loading. The browser resolves the missing directive by falling back to default-src, and if that fallback is permissive, scripts load from anywhere. Second: script-src is present but set to * (wildcard), which explicitly permits scripts from any origin. Third: the CSP contains script-src but default-src is the only restrictive directive, and the operator assumes script-src inherits restrictions it does not. In all three cases, the browser executes scripts from untrusted origins without objection.

Why it matters

Script execution is the highest-impact capability a browser grants to external content. A script runs with the full privileges of the page: it reads cookies, captures input, modifies the DOM, and makes network requests as the user. CSP exists primarily to restrict this capability. A policy that allows unrestricted script sources provides no defense against cross-site scripting, supply chain attacks through compromised CDNs, or unauthorized third-party code. The header is present but functionally empty. Automated scanners may report CSP as configured, masking the actual exposure.

How the fallback chain works

CSP directive resolution follows a specific precedence. When the browser evaluates whether a script should execute, it first checks for script-src. If script-src is not present in the policy, the browser falls back to default-src. If default-src is also absent, the browser permits the resource. This means a CSP like default-src 'self'; style-src 'self' has no script-src directive and no usable fallback — the browser permits scripts from any origin. The operator may believe default-src covers scripts, but only when default-src is explicitly set. A CSP that restricts images, styles, and fonts but omits script-src provides granular control over low-risk resources while leaving the highest-risk resource unrestricted.

The correct change

Add an explicit script-src directive that names the specific origins permitted to deliver JavaScript. At minimum, script-src should be set to 'self' to restrict scripts to the same origin. If third-party scripts are required, list each origin individually. Remove wildcard values. Do not rely on default-src as the sole control for script execution. An explicit script-src makes intent legible: the operator has decided which origins can execute code, and the browser enforces that decision.

Scope

This condition applies globally. CSP is delivered via HTTP response header or meta tag and governs the entire document. Every script element, external script reference, and dynamic script injection is subject to the script-src directive. A missing or wildcard script-src affects all pages sharing the same CSP configuration.

How to verify

• · Validation confirms the condition is resolved:
• · • Content-Security-Policy header contains an explicit script-src directive
• · • script-src does not include * (wildcard)
• · • script-src lists specific trusted origins rather than broad patterns
• · • default-src alone is not relied upon to restrict script execution
• · • Browser developer tools show script-src in parsed CSP
• · • Attempting to load a script from an unlisted origin triggers a CSP violation
• · • CSP violation reports confirm enforcement is active

Takeaway

• · script-src is the most consequential directive in any Content Security Policy
• · Missing script-src falls back to default-src; if default-src is absent or permissive, scripts are unrestricted
• · Wildcard script-src explicitly permits scripts from any origin, defeating CSP entirely
• · Explicit script-src with named origins is the minimum effective configuration

FAQ