CSP Keywords

Content Security Policy keywords are special values that define how resources can be loaded and executed in your web application. Understanding these keywords is crucial for implementing effective security policies.

Secure Keywords

'self' Allows the resource to be loaded and executed
'none' No sources are allowed
'strict-dynamic' Allows all inline scripts and inline event handlers injected by a script already allowed by the CSP
'report-sample' Includes samples of violating code in CSP violation reports for easier debugging

'self'

The 'self' keyword allows resources to be loaded from the same origin as the document containing the CSP header. The origin is defined by the scheme (http/https), domain, and port.

Example of using 'self' keyword

Content-Security-Policy: default-src 'self';

Allowed:

https://www.example.com/script.js (same origin)
https://www.example.com/images/logo.png (same origin)
https://www.example.com:443/api/data (same origin, port 443 is implicit for HTTPS)

Blocked:

http://www.example.com/script.js (different scheme)
https://cdn.example.com/script.js (different subdomain)
https://www.example.org/script.js (different domain)
https://www.example.com:8080/api/data (different port)

'none'

The 'none' keyword blocks all resources of the specified type. It's the most restrictive option.

Example of using 'none' keyword

Content-Security-Policy: script-src 'none'; img-src 'none';

This policy blocks all scripts and images from loading.

'strict-dynamic'

The 'strict-dynamic' keyword is designed for modern web applications using JavaScript frameworks. It allows trusted scripts (those with a valid nonce or hash) to load additional scripts dynamically.

Example of using 'strict-dynamic' with nonce

Content-Security-Policy: script-src 'nonce-xyz123' 'strict-dynamic';

<script nonce="xyz123" src="main.js"></script>

Important Notes:

'strict-dynamic' ignores whitelist sources ('self', URLs) if a nonce or hash is present
Must be used with a protection mechanism (nonce or hash)
Allows dynamic script loading from trusted sources

'report-sample'

The 'report-sample' keyword includes a sample of the violating code in violation reports sent to the specified reporting endpoint.

Example of using 'report-sample' keyword

Content-Security-Policy: script-src 'self'; report-uri /csp-violation-report-endpoint; report-sample;

Warning Keywords

'unsafe-inline' Allows inline scripts and styles (use with caution)
'unsafe-eval' Allows eval() and new Function() (use with caution)
'unsafe-hashes' Allows the resource to be loaded and executed

'unsafe-inline'

The 'unsafe-inline' keyword allows inline scripts and styles. This is one of the most dangerous options as it opens the door to XSS attacks.

Example of using 'unsafe-inline' keyword

Content-Security-Policy: script-src 'unsafe-inline';

<!-- Allowed but dangerous -->
<script>alert("Potentially dangerous!");</script>
<div style="color: red;">Red text</div>

Alternatives:

Use external JavaScript files
Use nonces or hashes
Refactor code to avoid inline scripts

'unsafe-eval'

The 'unsafe-eval' keyword allows the use of JavaScript functions that evaluate code from strings, such as eval(), new Function(), and string-based setTimeout()/setInterval().

Example of using 'unsafe-eval' keyword

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

// Dangerous if userInput is untrusted
let userInput = "alert('XSS')";
eval(userInput);

Alternatives:

Avoid eval() and similar functions
Use secure parsing methods (e.g., JSON.parse() for JSON data)

'unsafe-hashes'

The 'unsafe-hashes' keyword allows specific inline scripts to execute if their hashes match those specified in the CSP header.

Example of using 'unsafe-hashes' keyword

Content-Security-Policy: script-src 'sha256-jzgBGA4UWFFmpC6hS8HmB1FfsW5gPDyFF8R8gAAlR8=' 'unsafe-hashes';

<script>
  console.log('Allowed script');
</script>