Content Security Policy

Content Security Policy (CSP) is a security mechanism that helps to protect websites and web applications from various types of attacks, such as cross-site scripting (XSS) and clickjacking. CSP works by defining a set of rules that specify which sources are allowed to load and execute content on a website or web application. In this blog post, we will discuss what CSP is, how it works, and how it can help to improve the security of your website or web application.

What is Content Security Policy?

Content Security Policy is a mechanism that is used to control which sources are allowed to load and execute content on a website or web application. This is accomplished by defining a set of rules that specify which sources are permitted to load and execute content, and which sources are not.

For example, a CSP rule might allow content from a specific domain (e.g. "example.com") to be loaded and executed, while blocking content from other domains. This can help to prevent attackers from loading and executing malicious content on your website or web application, such as scripts that could be used to steal sensitive data or perform other types of attacks.

How does Content Security Policy work?

CSP works by defining a set of rules that specify which sources are allowed to load and execute content on a website or web application. These rules are typically defined in the HTTP headers of the website or web application, and are enforced by the browser when the website or web application is loaded.

For example, a CSP rule might look like this:

Content-Security-Policy: default-src 'self'; img-src 'self' https://example.com; script-src 'self' https://example.com

This rule specifies that content should be loaded and executed only from the domain of the website or web application (i.e. "self"), except for images and scripts, which are allowed to be loaded from the domain of the website or web application and from the "example.com" domain.

When the browser loads the website or web application, it will enforce these rules by only allowing content to be loaded and executed from the specified sources. Any content that is not from one of the specified sources will be blocked by the browser.

To build your own CSP Rules for your website, check out Report URI.

Here are some examples of CSP rules:

• default-src 'self'; - This rule specifies that content should be loaded and executed only from the domain of the website or web application.
• default-src 'none'; script-src 'self' https://example.com; - This rule specifies that no content should be loaded or executed by default, except for scripts, which are allowed to be loaded from the domain of the website or web application and from the "example.com" domain.
• default-src 'self'; img-src 'self' https://example.com; style-src 'self' https://example.com; - This rule specifies that content should be loaded and executed only from the domain of the website or web application, except for images and stylesheets, which are allowed to be loaded from the domain of the website or web application and from the "example.com" domain.
• default-src 'self'; frame-ancestors 'none'; - This rule specifies that content should be loaded and executed only from the domain of the website or web application, and that the website or web application should not be embedded in any frames or iframes. This can help to prevent clickjacking attacks.

CSP Hashes

CSP hashes are a way of specifying the exact content that is allowed to be loaded and executed by a website or web application. This is accomplished by generating a cryptographic hash of the content, which is then included in the CSP rules as a reference. When the website or web application is loaded, the browser will compute the hash of the content and compare it to the reference in the CSP rules. If the hashes match, the content will be allowed to load and execute. If the hashes do not match, the content will be blocked by the browser.

CSP hashes are typically used in conjunction with other CSP rules, such as the script-src or style-src rules. For example, a CSP rule might look like this:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com 'sha256-QkZiMzI1MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=';

In this example, the script-src rule specifies that scripts are allowed to be loaded from the domain of the website or web application, from the "example.com" domain, and from a specific script that has been hashed with the sha256 algorithm. The browser will compute the hash of the script and compare it to the reference in the CSP rule. If the hashes match, the script will be allowed to load and execute. If the hashes do not match, the script will be blocked by the browser.

A disadvantage of using CSP hashes is that they can be difficult to manage and update. When the content of your website or web application changes, you will need to generate new hashes and update the CSP rules accordingly. This can be time-consuming and error-prone, especially for websites or web applications with a large amount of content.

CSP Nonce

A CSP nonce is a randomly generated value that is used to specify the exact content that is allowed to be loaded and executed by a website or web application. This is accomplished by including the nonce in the CSP rules as a reference, and also as a part of the content itself. When the website or web application is loaded, the browser will compute the nonce of the content and compare it to the reference in the CSP rules. If the nonces match, the content will be allowed to load and execute. If the nonces do not match, the content will be blocked by the browser.

CSP nonces are typically used in conjunction with other CSP rules, such as the script-src or style-src rules. For example, a CSP rule might look like this:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com 'nonce-abc123';

In this example, the script-src rule specifies that scripts are allowed to be loaded from the domain of the website or web application, from the "example.com" domain, and from a specific script that has been tagged with the nonce value of "abc123". The browser will compute the nonce of the script and compare it to the reference in the CSP rule. If the nonces match, the script will be allowed to load and execute. If the nonces do not match, the script will be blocked by the browser.

<script nonce="abc123">
  // Your script code here
</script>

An advantage of using CSP nonces is that they are easier to manage and update than CSP hashes. Since the nonce values are randomly generated, they do not need to be recomputed whenever the content of your website or web application changes. This can make it simpler to implement and maintain CSP rules that use nonces, compared to using hashes.

Report Only Mode

Content Security Policy (CSP) Report Only mode is a way of testing and enforcing CSP rules without blocking content that does not comply with the rules. In Report Only mode, the CSP rules are still applied to the website or web application, but any content that violates the rules is not blocked. Instead, a report is generated and sent to a specified URL, which can be used to analyze and identify any potential violations of the CSP rules.

Report Only mode is useful for testing and debugging CSP rules, as it allows you to see how the rules would be applied to your website or web application without actually blocking any content. This can help you to identify and fix any issues with your CSP rules, such as rules that are too strict or rules that are not properly configured.

To enable Report Only mode for CSP, you can add the Content-Security-Policy-Report-Only HTTP header to your website or web application, and specify the CSP rules that you want to test. For example:

Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' https://example.com;

Here, the Content-Security-Policy-Report-Only header specifies that the CSP rules should be applied in Report Only mode, and the default-src and img-src directives define the CSP rules that will be tested. Any content that violates these rules will not be blocked, but a report will be generated and sent to the specified URL.

To view the reports that are generated in Report Only mode, you can specify a URL for the reports to be sent to using the report-uri directive in the CSP rules. For example:

Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' https://example.com; report-uri https://example.com/csp-reports

In this example, the report-uri directive specifies that the reports should be sent to the "https://example.com/csp-reports" URL. You can then use this URL to view the reports and analyze any potential violations of the CSP rules.

How can Content Security Policy improve the security of your website or web application?

Content Security Policy can help to improve the security of your website or web application by preventing attackers from loading and executing malicious content. By defining a set of rules that specify which sources are allowed to load and execute content, CSP can help to prevent attackers from injecting malicious scripts or other types of content into your website or web application.

In addition, CSP can help to protect against various types of attacks, such as cross-site scripting (XSS) and clickjacking. XSS attacks involve injecting malicious scripts into a website or web application, which can be used to steal sensitive data or perform other malicious actions. Clickjacking involves tricking users into clicking on buttons or links that perform unintended actions, such as downloading malware or revealing sensitive information. By defining strict CSP rules, you can help to prevent these types of attacks and improve the security of your website or web application.

Browser Support

Most modern browsers support Content Security Policy (CSP), including Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari, and others. CSP is typically enabled by default in these browsers, and can be configured using the HTTP headers of a website or web application.

However, not all browsers support all features of CSP. For example, some older versions of browsers may not support certain CSP directives or features, such as the worker-src directive or the unsafe-inline keyword. In these cases, the browser will either ignore the unsupported CSP rules or treat them as errors, depending on the specific implementation.

In general, it is recommended to use the latest version of a supported browser to ensure the best compatibility with CSP. You can also use feature detection techniques to check for the availability of specific CSP features in the browser, and adjust your CSP rules accordingly. This can help to ensure that your website or web application works properly with CSP, even on older or less-capable browsers

For a comprehensive list of Browser Support: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#browser_compatibility