Identify the blocked script and current policy
Identify the exact Content Security Policy directive and trusted script before making a narrow policy correction.
A CSP console message names what the browser refused to execute; policy changes still need the script's provenance. Record the affected page, script URL or inline script identifier, blocked directive, time and expected function. Compare the script with the application owner’s approved build or supplier inventory before changing the policy. If the page instead tries to load an HTTP resource over HTTPS, use the mixed-content path.
Content Security Policy limits what the browser may load or run, including JavaScript. It may be delivered in an HTTP header or an HTML meta element, with different capabilities. The application owner should identify which policy source controls the affected page and keep a copy of the last known-good version.
Check the directive and resource path
Inspect the console’s exact blocked-resource message and the page response’s Content-Security-Policy header or authorised meta policy. For external scripts, compare the script origin with the policy’s effective script-src or fallback directive. For an inline script, a host allowlist alone may not solve the violation; the owner may need a supported nonce or hash design. If multiple policies apply, a more restrictive one can still block the resource. Do not assume a policy set in the application is the only one if an in-scope intermediary also sends a header.
Check whether the blocked URL was expected for this release and is served over the intended HTTPS origin. A changed supplier domain or unexpected injected script deserves investigation, not automatic allowlisting. Do not paste sensitive page data or entire response bodies into a public report.
Make the smallest reviewed application change
If the script provenance and need are confirmed, the application owner can update only the relevant policy source or fix the application’s script URL, following its framework’s release process. Preserve the prior policy for rollback and test in an authorised preview where available. Avoid removing CSP, allowing every origin, or adding unsafe-inline or unsafe-eval as a generic fix; those changes weaken the control far beyond one trusted resource. If the header is set by the contracted platform rather than the application, send the safe directive and URL evidence to the operator for a scoped review.
Check the function and the policy boundary
Reload the affected page in a fresh session and exercise the failed function. Confirm the expected script loads and the console no longer reports its violation. Also verify an unrelated untrusted test origin remains blocked through an approved test or policy review. If a new policy broadens access unexpectedly or another resource fails, restore the previous policy and revise the proposed change. A cleared console warning alone is insufficient if the application function still fails.
For example, if one first-party script is blocked, allow its exact origin or a supported nonce and retest the feature. Confirm that an unrelated script remains blocked; a wildcard allowance would hide the original boundary.
Frequently asked questions
Is a blocked script necessarily safe to allow? No. Confirm its owner, version and purpose first.
Would removing CSP fix the page? It may hide the symptom while removing a security boundary. Prefer a reviewed narrow correction or rollback.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.