Values
Most of the directives allow you to specify a list of values. These values can be an <host-source>, a <keyword>, <hash> or <nonce>. The values are separated by a space. The following sections describe how to define those values.
<host-source>
<host-source>
The host source allow you to specify the host from which resources can be loaded. Host are defined by their scheme, host, port, and path as the following format:
[scheme://] <host> [:port] [/path]
Examples:
- https://example.com
- https://example.com:443
- https://subdomain.example.com/path
- example.com
Security Best Practice
While wildcards (*) provide flexibility, they should be used sparingly. Each wildcard increases the attack surface by allowing resources from potentially malicious sources. Always prefer specific host sources over wildcards when possible.
scheme - Optional
The scheme component of a host-source specifies the protocol used to access the resource.
HTTPS Recommendation
Always prefer 'https:' over unspecified or 'http:' schemes. Using HTTPS ensures that resources are loaded securely and helps prevent man-in-the-middle attacks.
Available schemes
https
wss
http
ws
Notes
If the scheme source is not defined, the document origin's scheme is used.
Secure upgrades are allowed, so if the document is loaded using https:, then example.com will match https://example.com but not http://example.com
When matching schemes, secure upgrades are allowed (e.g. specifying http://example.com will match https://example.com).
The use of http and ws is allowed but not recommended as it is not encrypted, do not use unless it is necessary
host - required
The host component of a host-source specifies the domain or IP address from which resources can be loaded.
IP Address Usage
Using IP addresses in host-sources is not recommended for production environments. They are harder to maintain, may change unexpectedly, and could bypass DNS-based security controls. Always prefer domain names unless absolutely necessary.
Hosts can be defined as :
subdomain.domain.com
domain.com
ip-address
*.subdomain.domain.com
*.domain.com
*
Notes
The use of wildcard is allowed but not recommended as it is too broad, do not use unless it is necessary
The use of IP address is allowed but not recommended, please define the domain name instead
port - Optional
The port component of a host-source specifies the port number used to access the resource.
Port Specification
If no port is specified, the default port for the scheme is used (80 for HTTP, 443 for HTTPS). Only specify ports when you need to allow resources from non-standard ports.
Port can be defined as :
Any number between 0 and 65535.
Any number between 0 and 65535.
Note
If using http or ws, the port is optional and will default to 80.
If using https or wss, the port is optional and will default to 443.
Instead of the port number, you can use a wildcard *, which will allow any port number.
path - Optional
The path component of a host-source specifies the path to the resource on the server.
Path Restrictions
When using paths in your host-source, be aware that they follow an exact matching pattern. A path of /api/ will not match /api/v1/. Consider using wildcards carefully if you need to match multiple paths under a directory.
Path can be defined as the following :
/path/to/file.js
/path/to/folder/
Notes
Wildcard cannot be used in the path.
If the path end with a /, the CSP will allow all resources under that path.
Examples
Matches all attempts to load from any subdomain of domain.com. Also matches https resources.
http://*.domain.comMatches all attempts to load from port 443 on a subdomain.domain.com.
subdomain.domain.com:443Matches all attempts to access subdomain.domain.com using https:.
https://subdomain.domain.comMatches all attempts to load from any subdomain of domain.com.
*.domain.comMatches all attempts to load from any subdomain of domain.com using https: on port 42, and only if the path is /path/to/file.js.
https://*.domain.com:42/path/to/file.jsMatches all attempts to load from a domain.com using ws:. Also matches wss resources.
ws://domain.com
<scheme-source>
<scheme-source>
The scheme source is used to allow all source matching the specified scheme. It is not recommended using it as allowing any sources matching a scheme does not provide any security.
Security Warning: Use of Unsafe Schemes
Be extremely cautious when using schemes. These schemes can potentially allow attackers to bypass CSP protections by injecting malicious content. Only use these schemes when absolutely necessary and ensure you understand the security implications.
Available schemes
http:
Allow any sources using http:
Allow any sources using http:
https:
Allow any sources using https:
Allow any sources using https:
data:
Allow data: URls
Allow data: URls
mediastream:
Allow mediastream: URIs
Allow mediastream: URIs
blob:
Allow blob: URIs
Allow blob: URIs
filesystem:
Allow filesystem: URIs
Allow filesystem: URIs
Notes
None of those schemes are recommended to be used as it does not provide any security
Examples
Allow all sources using data: URI, like : An image encoded in Base64 format or any encoded script such as : data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg== which can be used to load a malicious script
data:Allow all sources using https: such as : https://domain.com, https://maliciouswebsite.com.
https:
<keyword>
<keyword>
Keywords are used to define a specific source or behavior for the Content-Security-Policy. The keywords are always defined between single quotes.
Safe keywords
'none'
Using 'none' keyword will prevent any source to loaded using this directive.
Using 'none' keyword will prevent any source to loaded using this directive.
'self'
Using 'self' keyword will allow only the sources using the same origin of current the document.
Using 'self' keyword will allow only the sources using the same origin of current the document.
'strict-dynamic'
Using 'strict-dynamic' keyword will allow the scripts allowed with nonce or hashes to load additional scripts.
Using 'strict-dynamic' keyword will allow the scripts allowed with nonce or hashes to load additional scripts.
'report-sample'
Using 'report-sample' keyword will collect a 40-character sample for inline script and style violations, and include it in the violation report.
Using 'report-sample' keyword will collect a 40-character sample for inline script and style violations, and include it in the violation report.
'inline-speculation-rules'
Using 'inline-speculation-rules' keyword will allow inline speculation rules without permitting inline scripts
Using 'inline-speculation-rules' keyword will allow inline speculation rules without permitting inline scripts
Notes
All the keywords are case-sensitive and must be defined between single quotes.
default-src should always be set to 'none' and add the required sources using the other directives.
If 'strict-dynamic' is defined and supported by the browser, the browser will ignore all the other sources defined in the directive. If the browser does not support 'strict-dynamic', it will fall back to the other sources defined in the directive.
Unsafe keywords
'unsafe-eval'
Using 'unsafe-eval' keyword will allow the use of function that create code from string as eval(), setTimeout(), setInterval() Function() and window.setImmediate().
Using 'unsafe-eval' keyword will allow the use of function that create code from string as eval(), setTimeout(), setInterval() Function() and window.setImmediate().
'wasm-unsafe-eval'
Using 'wasm-unsafe-eval' keyword will allow WebAssembly to use eval(), setTimeout(), setInterval() Function() and window.setImmediate() functions to create code from string.
Using 'wasm-unsafe-eval' keyword will allow WebAssembly to use eval(), setTimeout(), setInterval() Function() and window.setImmediate() functions to create code from string.
'unsafe-hashes'
Using 'unsafe-hashes' keyword will allow the use of inline scripts that contains eventListeners
Using 'unsafe-hashes' keyword will allow the use of inline scripts that contains eventListeners
'unsafe-inline'
Using 'unsafe-inline' keyword will allow the use of inline scripts and styles depending on the directive where it is used
Using 'unsafe-inline' keyword will allow the use of inline scripts and styles depending on the directive where it is used
Notes
To remove the unsafe keywords from the directives, all the scripts must be moved to external files and hash and nonce must be used to allow the scripts to be loaded.
The use of unsafe keywords is highly discouraged as it can lead to security vulnerabilities.
Security Warning: Unsafe Keywords
Using unsafe keywords like 'unsafe-inline' and 'unsafe-eval' significantly weakens your Content Security Policy. These keywords bypass core CSP protections and should only be used as a last resort when no other solution is possible. Instead, consider using nonces or hashes for inline scripts, and restructuring code to avoid eval().
Examples
Allow the use of eval() function to create code from string
Content-Security-Policy : default-src 'none' ; script-src 'unsafe-eval'Allow the use of inline scripts and styles
Content-Security-Policy : default-src 'none' ; script-src 'unsafe-inline' ; style-src 'unsafe-inline'Allow the use of inline scripts that contains eventListeners
Content-Security-Policy : default-src 'none' ; script-src 'unsafe-hashes' ;
<hash> & <nonce>
<hash> & <nonce>
The hash source is used to allow specific inline resources to be loaded. The hash source is defined by the hash algorithm and the hash value. The hash value is a base64-encoded cryptographic hash of the resource.
hash and nonce can be defined as the following
'nonce-<random-value>'
Nonce value is a random value that is generated for each request. The nonce value must be defined in the script tag or style tag using the nonce attribute.
Nonce value is a random value that is generated for each request. The nonce value must be defined in the script tag or style tag using the nonce attribute.
'sha*-*'
The hash value is a base64-encoded cryptographic hash of the resource. The hash value is defined by the hash algorithm and the hash value.
The hash value is a base64-encoded cryptographic hash of the resource. The hash value is defined by the hash algorithm and the hash value.
Notes
nonce must be different for each request, if the nonce value is the same for each request, it will be considered as unsafe.
Examples
Allow the script to be loaded only if the hash value is equal to the one defined
Content-Security-Policy : default-src 'none' ; script-src 'self' 'sha256-GNF74DLkXb0fH3ILHgILFjk1ozCF3SNXQ5mQb7WLu/Y='Allow the script to be loaded only if the nonce value on the script tag is equal to the one defined
Content-Security-Policy : default-src 'none' ; script-src 'self' 'nonce-YmQ1NTY0ZTctNzllYy00NzIyLThmZGYtMzI2ZWQ3N2JkZTE5'Allow the style to be loaded only if the hash value in the style tag is equal to the one defined
Content-Security-Policy : default-src 'none' ; style-src 'self' 'sha256-GNF74DLkXb0fH3ILHgILFjk1ozCF3SNXQ5mQb7WLu/Y='
Best Practice: Use Nonces Over Hashes
While both nonces and hashes can be used to allow specific inline scripts, using nonces is generally recommended for better maintainability. Nonces can be generated server-side and rotated automatically, while hashes need to be manually updated whenever the inline script content changes. This makes nonces more flexible and easier to maintain in dynamic applications.