---

Example Policy

Assume a Content-Security-Policy header is set with the following policy:

script-src 'self' https://js.example.com;

Allows

With the above CSP policy, the following are allowed to load and execute in the browser:

<!-- allowed by 'self' -->
<script src="/js/some-file.js"></script>
<!-- allowed by https://js.example.com -->
<script src="https://js.example.com/file.js"></script>

Blocks

The Example Policy above will block the following from loading or executing in the browser:

<script src="https://attacker.example.com/file.js"></script>

Blocked because attacker.example.com is not in the source list.

<script>
  runInlineScript();
</script>

Blocked because inline scripts are blocked by default, you have to use hashes or a nonce (CSP Level 2) to allow inline scripts to run.

<button onClick="runInlineScript();">
  All JS Event Handlers Blocked
</button>

The execution of all JS event handlers from inline HTML markup are blocked default, onclick, onload, onmouseover, onsubmit, etc. You can get them to work via a 'unsafe-hashes' source list expression, however that is only supported on CSP Level 3 browsers.

<a href="javascript:runInlineScript();">Won't Run</a>

There is no way to get javascript: to work when CSP is enabled except for unsafe-inline.

The script-src-elem and script-src-attr Directives

The CSP Level 3 specification added support for two new directives that are a subset of script-src

• script-src-elem - Applies only to script tags and blocks, it does not apply to inline event handlers like onclick
• script-src-attr - Applies only to script attribute such as onclick, onmouseover, etc.

The script-src-elem and script-src-attr directives are supported on Chrome and Firefox, but not yet supported on Safari. For that reason it is recommended to use script-src instead when possible.

Common Error Messages

When the browser blocks execution of your JavaScript due to a Content-Security-Policy header in place with a script-src directive you can find the reason in the browser developer tools console. Here are some examples:

content security policy: the page's settings blocked the loading of a resource at inline ("script-src").

This error message means that the loading of inline script was blocked by the content security policy. The resource at inline could be a script tag with JavaScript inside it. Or the resource at inline could be an inline JavaScript event handler (such as onclick). Where the message mentions the page’s settings, it is referring to the Content-Security-Policy header or meta tag.

You can workaround the blocked loading of inline scripts error by using hashes or a nonce, or by moving the script into a JS file.

refused to execute inline event handler 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. note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

This error indicates that you have an inline event handler like onclick in your code that will be blocked. You might want to look at the documentation for unsafe-hashes keyword as well.

content security policy of your site blocks the use of 'eval' in javascript

Content-Security-Policy will block JavaScript eval() calls by default. You can use unsafe-eval to get around the error, but then you may be opening up more security holes. It is usually better to rewrite the JavaScript to avoid eval.

Browser Support for script-src

The CSP script-src directive has been part of the Content Security Policy Specification since the first version of it (CSP Level 1). However some features such as hashes and nonces were introduced in CSP Level 2. Support for these features is still very good.

Internet Explorer 11 and below do not support the script-src directive. This means that IE11 will simply ignore the policy and allow any script to run (as if a policy had not been set at all).

---