Refused to load the script 'https://cdn.example.com/lib.js' because it violates the following Content Security Policy directive: "script-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
Your site sends a Content-Security-Policy header, and the script's origin, inline code or eval use is not in the allowed list, so the browser blocks it. Add the exact source to script-src, or use a nonce or hash for inline scripts, in whichever place actually sends the header.
Also appears as:Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. · Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'". · Content-Security-Policy: The page's settings blocked the loading of a resource (script-src-elem) at https://cdn.example.com/lib.js because it violates the following directive: "script-src 'self'" · Refused to load the script because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
Common causes
A new CDN, analytics or widget script whose origin is not listed in script-src
Inline <script> blocks or onclick attributes under a policy without nonces or hashes
A library using eval() or new Function() under a policy without 'unsafe-eval'
A strict default-src with no script-src, so default-src applies to scripts too
Two policies sent at once (for example a plugin header and a <meta> tag), where the request must satisfy both
Scripts that load further scripts from another domain not in the policy
How to fix it
Read the blocked source and directive. The console message names the blocked URL and the directive it violated. Note whether it is an external URL, an inline script or eval.
Find where the policy is set. Check the response headers in DevTools > Network for Content-Security-Policy, and look for <meta http-equiv="Content-Security-Policy"> in the HTML. It may come from Nginx, Apache, the app or a security plugin.
Allow external sources precisely. Add the specific origin to script-src, for example script-src 'self' https://cdn.example.com. Avoid broad entries such as https: or *.
Use nonces or hashes for inline scripts. Generate a random nonce per response, add 'nonce-<value>' to script-src and nonce="<value>" to each script tag. For fixed inline scripts, add 'sha256-<base64 hash>' of the exact script text.
Test with Report-Only first. Send the new policy as Content-Security-Policy-Report-Only to see violations in the console without breaking the page, then switch to the enforcing header.
That removes most of the XSS protection CSP provides. Use nonces or hashes instead; when a nonce or hash is present, browsers that support them ignore 'unsafe-inline'.
Why is my script blocked even though I added it to the policy?
Often a second policy is also being sent, and a script must pass every policy. Check all Content-Security-Policy headers and meta tags in the response.
Can an SRI hash be used in CSP?
For inline scripts, the CSP hash is the base64 SHA-256/384/512 of the exact script text, in the same format as an SRI hash. For external scripts, CSP Level 3 browsers can match a hash in script-src against the script's integrity attribute.