script-src-elem
script-src-elem
script-src-elem
The script-src-elem directive specifies valid sources for JavaScript <script> elements, but not inline script event handlers like onclick. It allows you to control where <script> tags can load JavaScript from, providing an additional layer of security for your web application.
Recommended Values
'self'
Allows scripts from the same origin
Allows scripts from the same origin
https://subdomain.domain.com
Allows scripts from a specific external site
Allows scripts from a specific external site
nonce-<random>
Allows scripts with a specific nonce value
Allows scripts with a specific nonce value
'sha256-<hash>'
Allows scripts that match a specific hash
Allows scripts that match a specific hash
'report-sample'
Includes samples of blocked scripts in violation reports to help with debugging
Includes samples of blocked scripts in violation reports to help with debugging
Explore detailed value definitions
Tips & Tricks
Using 'report-sample' is recommended as it includes samples of blocked scripts in violation reports, helping with debugging.
This directive is more specific than script-src and only applies to <script> elements, not to inline event handlers or JavaScript: URLs.
Using 'unsafe-inline' with this directive can be risky. Consider using nonces or hashes instead for inline scripts.
When using hashes, make sure to include the 'unsafe-hashes' source expression if you need to allow event handlers and JavaScript: URLs.
Available Values
'self'
Allows scripts from the same origin
Allows scripts from the same origin
'none'
Blocks all scripts
Blocks all scripts
'nonce-<random>'
Allows scripts with a matching nonce attribute
Allows scripts with a matching nonce attribute
'sha256-<hash>'
Allows scripts matching a specific hash value
Allows scripts matching a specific hash value
https://example.com
Allows scripts from specific trusted domains
Allows scripts from specific trusted domains
'strict-dynamic'
Allows scripts loaded by trusted scripts, ignoring static allowlist
Allows scripts loaded by trusted scripts, ignoring static allowlist
'report-sample'
Includes script samples in violation reports for debugging
Includes script samples in violation reports for debugging
'unsafe-inline'
Allows inline scripts in <script> tags (not recommended)
Allows inline scripts in <script> tags (not recommended)
'unsafe-eval'
Allows use of eval() and similar functions (strongly discouraged)
Allows use of eval() and similar functions (strongly discouraged)
Examples
Allows scripts from the same origin and a specific external site
Content-Security-Policy: script-src-elem 'self' https://example.com;Allowed
<!-- allowed by 'self' --> <script src='/js/app.js'></script> <!-- allowed by https://example.com --> <script src='https://example.com/js/library.js'></script>Blocked
<!-- blocked as the domain is not authorized --> <script src='https://malicious.website.com/js/script.js'></script> <!-- blocked as inline scripts are not allowed --> <script>alert('Hello');</script>
Frequently Asked Questions
What is the script-src-elem directive used for?
The script-src-elem directive controls which script elements (<script> tags) can be loaded and executed on your page. It provides more granular control than script-src by specifically targeting script elements while excluding other JavaScript contexts like event handlers.
Default Behavior
If script-src-elem is not specified, the browser falls back to script-src directive, which then falls back to default-src if needed.
How does script-src-elem differ from script-src?
While script-src controls all JavaScript sources, script-src-elem specifically governs <script> elements, both inline and external. This allows for more precise control over script elements while leaving other JavaScript contexts (like event handlers) to be controlled by other directives.
Security Note
Using 'unsafe-inline' with script-src-elem is dangerous as it allows any inline scripts. Consider using nonces or hashes instead.
What are the recommended values for script-src-elem?
The most secure approach is to use 'self' to allow scripts from your own domain, along with specific trusted domains for third-party scripts. For inline scripts, use nonces or hashes instead of 'unsafe-inline'. The 'strict-dynamic' keyword can be useful when implementing nonce-based CSP.
Best Practice
Always prefer loading scripts from trusted sources over inline scripts. When inline scripts are necessary, use nonces or hashes for better security.
Need to monitor CSP violations and maintain it easily?
Set up a reporting endpoint to monitor Content Security Policy violations in real-time to build and maintain your CSP easily.
Set up your endpoint now