script-src-elem

Relationship with script-src

• script-src-elem controls the loading and execution of <script> elements and their contents
• script-src serves as a fallback when script-src-elem is not specified
• script-src-elem is more specific than script-src for <script> elements
• Both directives can be used together to create a more granular security policy

• Use script-src-elem to control <script> elements specifically
• Use script-src as a fallback for other JavaScript execution contexts
• Or use script-src as the primary control and let script-src-elem inherit from it

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

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

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 be used to allow specific inline scripts. See the values section for more information.

• Do not use 'unsafe-inline' as it may introduce security vulnerabilities.

• Do not use 'unsafe-hashes' as it may introduce security vulnerabilities.

• 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-hashes': Allows inline scripts (insecure)

Example Configurations

Example policy with nonce

Content-Security-Policy: script-src-elem '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>

Additional Information

• The script-src-elem directive is crucial for controlling <script> elements specifically
• Consider using 'strict-dynamic' when working with third-party scripts
• Use nonces or hashes instead of 'unsafe-inline' for better security
• This directive specifically controls <script> elements, while script-src serves as a fallback

Related Resources

External Articles

• MDN Web Docs: script-src-elem
• OWASP: Content Security Policy Cheat Sheet
• Google Web Fundamentals: Content Security Policy

Related Documentation Sections

• script-src Directive
• script-src-attr Directive
• CSP Reporting and Monitoring
• CSP Best Practices