script-src

The script-src directive controls which JavaScript sources can be loaded and executed in your web application. It's one of the most critical CSP directives as it directly impacts the security of your application's JavaScript execution.

Recommended Values

'self' Allows the resource to be loaded and executed
https://subdomain.domain.com/path Allows the resource to be loaded and executed
'sha256-<hash>' Allows the resource to be loaded and executed
'nonce-<random>' Allows the resource to be loaded and executed
'report-sample' Includes samples of violating code in CSP violation reports for easier debugging
'strict-dynamic' Allows all inline scripts and inline event handlers injected by a script already allowed by the CSP
Explore detailed value definitions

Recommended script-src configuration

Content-Security-Policy: script-src 'self' https://trusted-cdn.com;

Relationship with script-src-elem and script-src-attr

The script-src directive is a shorthand that encompasses both script-src-elem and script-src-attr directives:

script-src-elem controls the loading and execution of <script> elements and their contents
script-src-attr specifically controls event handler attributes (like onclick, onload, etc.)
If either of these more specific directives is not specified, the browser falls back to the rules specified in script-src

Using these directives together allows for more granular control over JavaScript execution. For example, you might want to:

Allow external scripts from trusted CDNs via script-src-elem
Block all inline event handlers via script-src-attr
Or create other combinations based on your security requirements

Tips & Tricks

The nonce value must be unique for each request and must be the same as the one specified in the Content-Security-Policy header.
Hashes can also be used to allow specific scripts. See the values section for more information.
Do not use 'unsafe-inline' 'unsafe-eval' or 'unsafe-hashes' as it may introduce security vulnerabilities. Use with caution.
Using broad keywords like 'data:' 'blob:' 'http:' 'https:' is too permissive and may introduce security vulnerabilities. Use with caution.

Possible Values

'none': No scripts are allowed
'self': Only scripts from the same origin are allowed
'strict-dynamic': Trusts explicitly marked scripts and their dependencies
'report-sample': Includes a sample of the violating code in violation reports
Nonces: 'nonce-<random>' for specific inline scripts
Hashes: 'sha256-<hash>' for specific inline scripts
URLs: Specific domains (e.g., https://trusted-cdn.com)
Schemes: Protocol schemes (e.g., https:)
⚠️ 'unsafe-inline': Allows inline scripts (insecure)
⚠️ 'unsafe-eval': Allows dynamic code evaluation (insecure)

Example Configurations

Example policy with nonce

CSP Header with nonce

Content-Security-Policy: script-src 'self' 'nonce-random123' https://trusted-cdn.com;

Allowed

<!-- allowed as it has the correct nonce -->
<script nonce="random123">alert('Hello');</script>

<!-- allowed as it's from trusted-cdn.com -->
<script src="https://trusted-cdn.com/script.js"></script>

<!-- allowed as it's from same origin -->
<script src="/script.js"></script>

Blocked

<!-- blocked as it has no nonce -->
<script>alert('Blocked!');</script>

<!-- blocked as it has wrong nonce -->
<script nonce="wrong">alert('Blocked!');</script>

<!-- blocked as the domain is not authorized -->
<script src="https://malicious.com/script.js"></script>

<!-- blocked as eval is not allowed -->
eval('alert("Blocked!")');

<!-- blocked as new Function is not allowed -->
new Function('alert("Blocked!")')();

Additional Information

The script-src directive is crucial for preventing XSS attacks
Consider using 'strict-dynamic' when working with third-party scripts
Use nonces or hashes instead of 'unsafe-inline' for better security
The 'unsafe-eval' directive is often needed for frameworks but should be carefully evaluated