Content-Security-Policy: script-src directive

Baseline Widely available *

This feature is well established and works across many devices and browser versions. It’s been available across browsers since August 2016.

* Some parts of this feature may have varying levels of support.

The HTTP Content-Security-Policy (CSP) script-src directive specifies valid sources for JavaScript. This includes not only URLs loaded directly into

Note that inline event handlers are blocked as well:

html

You should replace them with addEventListener calls:

document.getElementById("btn").addEventListener("click", doSomething);

If you cannot replace inline event handlers, you can use the 'unsafe-hashes' source expression to allow them. See Unsafe hashes for more information.

Allowlisting external scripts using hashes

Allowing trusted domains, as shown in the section above, is a broad-brushed approach for specifying the locations from which code can safely be loaded. This is a pragmatic approach, in particular when your site uses many resources and you have confidence that the trusted site will not be compromised.

An alternative method is to specify allowed scripts using file hashes. Using this approach an external file in a

The integrity attribute can have multiple values, each providing a hash for the file calculated using a different algorithm. In order for an external script to be loaded, CSP requires that all valid hash values in the attribute must also be in the CSP script-src declaration. Therefore the script below would not load, because the second hash is not present in the CSP header above.

html

This rule only applies to valid hash values. Values that are not recognized as hashes by the browser are ignored, so the following script should load:

html

Subresource integrity contains more information about calculating hashes and using the integrity attribute.

Unsafe inline script

Note: Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides. If you absolutely have to use them, there are a few mechanisms that will allow them. Hashes apply to inline scripts and styles, but not event handlers. See Unsafe hashes for more information.

To allow inline scripts and styles, 'unsafe-inline', a nonce-source or a hash-source that matches the inline block can be specified. The following Content Security Policy will allow all inline

Allowing all inline scripts is considered a security risk, so it's recommended to use a nonce-source or a hash-source instead. To allow inline scripts and styles with a nonce-source, you need to generate a random nonce value (using a cryptographically secure random token generator) and include it in the policy. It is important to note, this nonce value needs to be dynamically generated as it has to be unique for each HTTP request:

http

Content-Security-Policy: script-src 'nonce-2726c7f26c'

Then, you need to include the same nonce in the

Alternatively, you can create hashes from your inline scripts. CSP supports sha256, sha384 and sha512.

http

Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

When generating the hash, don't include the

Unsafe hashes

Policies for inline resources with hashes like script-src 'sha256-{HASHED_INLINE_SCRIPT}' allow scripts and styles by their hash, but not event handlers:

html

Instead of allowing 'unsafe-inline', you can use the 'unsafe-hashes' source expression if code can't be updated to equivalent addEventListener calls. Given a HTML page that includes the following inline event handler:

html

The following CSP header will allow the script to execute:

http

Content-Security-Policy:  script-src 'unsafe-hashes' 'sha256-{HASHED_EVENT_HANDLER}'

Unsafe eval expressions

The 'unsafe-eval' source expression controls several script execution methods that create code from strings. If a page has a CSP header and 'unsafe-eval' isn't specified with the script-src directive, the following methods are blocked and won't have any effect:

eval()
Function()
When passing a string literal like to methods like: setTimeout("alert(\"Hello World!\");", 500);
window.execScript() Non-standard (IE < 11 only)

Unsafe WebAssembly execution

The 'wasm-unsafe-eval' source expression controls WebAssembly execution. If a page has a CSP header and 'wasm-unsafe-eval' isn't specified in the script-src directive, WebAssembly is blocked from loading and executing on the page.

The 'wasm-unsafe-eval' source expression is more specific than 'unsafe-eval' which permits both compilation (and instantiation) of WebAssembly and, for example, the use of the eval operation in JavaScript. If the 'unsafe-eval' source keyword is used, then this overrides any occurrence of 'wasm-unsafe-eval' in the CSP policy.

http

Content-Security-Policy: script-src 'wasm-unsafe-eval'

strict-dynamic

The 'strict-dynamic' source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allowlist or source expressions such as 'self' or 'unsafe-inline' will be ignored.

For example, a policy such as script-src 'strict-dynamic' 'nonce-R4nd0m' https://allowlisted.example.com/ would allow loading of a root script with \n\n

Note that inline event handlers are blocked as well:\n

html\n\nYou should replace them with addEventListener calls:\n
jsdocument.getElementById(\"btn\").addEventListener(\"click\", doSomething);\n\nIf you cannot replace inline event handlers, you can use the 'unsafe-hashes' source expression to allow them.\nSee Unsafe hashes for more information."}},{"type":"prose","value":{"id":"allowlisting_external_scripts_using_hashes","title":"Allowlisting external scripts using hashes","isH3":true,"content":"
Allowing trusted domains, as shown in the section above, is a broad-brushed approach for specifying the locations from which code can safely be loaded.\nThis is a pragmatic approach, in particular when your site uses many resources and you have confidence that the trusted site will not be compromised.\n
An alternative method is to specify allowed scripts using file hashes.\nUsing this approach an external file in a \n\n
The integrity attribute can have multiple values, each providing a hash for the file calculated using a different algorithm.\nIn order for an external script to be loaded, CSP requires that all valid hash values in the attribute must also be in the CSP script-src declaration.\nTherefore the script below would not load, because the second hash is not present in the CSP header above.\n
html\n\nThis rule only applies to valid hash values.\nValues that are not recognized as hashes by the browser are ignored, so the following script should load:\nhtml\n\nSubresource integrity contains more information about calculating hashes and using the integrity attribute."}},{"type":"prose","value":{"id":"unsafe_inline_script","title":"Unsafe inline script","isH3":true,"content":"
\nNote:\nDisallowing inline styles and inline scripts is one of the biggest security wins CSP provides.\nIf you absolutely have to use them, there are a few mechanisms that will allow them.\nHashes apply to inline scripts and styles, but not event handlers.\nSee Unsafe hashes for more information.\n\n
To allow inline scripts and styles, 'unsafe-inline', a nonce-source or a hash-source that matches the inline block can be specified.\nThe following Content Security Policy will allow all inline \n\n
Allowing all inline scripts is considered a security risk, so it's recommended to use a nonce-source or a hash-source instead.\nTo allow inline scripts and styles with a nonce-source, you need to generate a random nonce value (using a cryptographically secure random token generator) and include it in the policy.\nIt is important to note, this nonce value needs to be dynamically generated as it has to be unique for each HTTP request:\n
httpContent-Security-Policy: script-src 'nonce-2726c7f26c'\n\nThen, you need to include the same nonce in the \n\n
Alternatively, you can create hashes from your inline scripts. CSP supports sha256, sha384 and sha512.\n
httpContent-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='\n\nWhen generating the hash, don't include the \n"}},{"type":"prose","value":{"id":"unsafe_hashes","title":"Unsafe hashes","isH3":true,"content":"
Policies for inline resources with hashes like script-src 'sha256-{HASHED_INLINE_SCRIPT}' allow scripts and styles by their hash, but not event handlers:\n
html\n\n\n\n\n\nInstead of allowing 'unsafe-inline', you can use the 'unsafe-hashes' source expression if code can't be updated to equivalent addEventListener calls.\nGiven a HTML page that includes the following inline event handler:\n
html\n\n\nThe following CSP header will allow the script to execute:\nhttpContent-Security-Policy:  script-src 'unsafe-hashes' 'sha256-{HASHED_EVENT_HANDLER}'\n"}},{"type":"prose","value":{"id":"unsafe_eval_expressions","title":"Unsafe eval expressions","isH3":true,"content":"The 'unsafe-eval' source expression controls several script execution methods that create code from strings.\nIf a page has a CSP header and 'unsafe-eval' isn't specified with the script-src directive, the following methods are blocked and won't have any effect:\n\neval()\n
Function()\n
\nWhen passing a string literal like to methods like: setTimeout(\"alert(\\\"Hello World!\\\");\", 500);\n\nsetTimeout()\n
setInterval()\n
setImmediate()\n\n\n
\nwindow.execScript() \nNon-standard\n (IE < 11 only)\n\n"}},{"type":"prose","value":{"id":"unsafe_webassembly_execution","title":"Unsafe WebAssembly execution","isH3":true,"content":"
The 'wasm-unsafe-eval' source expression controls WebAssembly execution.\nIf a page has a CSP header and 'wasm-unsafe-eval' isn't specified in the script-src directive, WebAssembly is blocked from loading and executing on the page.\n
The 'wasm-unsafe-eval' source expression is more specific than 'unsafe-eval' which permits both compilation (and instantiation) of WebAssembly and, for example, the use of the eval operation in JavaScript.\nIf the 'unsafe-eval' source keyword is used, then this overrides any occurrence of 'wasm-unsafe-eval' in the CSP policy.\n
httpContent-Security-Policy: script-src 'wasm-unsafe-eval'\n"}},{"type":"prose","value":{"id":"strict-dynamic","title":"strict-dynamic","isH3":true,"content":"The 'strict-dynamic' source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allowlist or source expressions such as 'self' or 'unsafe-inline' will be ignored.\n
For example, a policy such as script-src 'strict-dynamic' 'nonce-R4nd0m' https://allowlisted.example.com/ would allow loading of a root script with