The script-src Directive

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.

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).