CSP Content Security Policy §

XSS

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

To exploit vulnerabilities in an application, an attacker could use several payloads such as in-line code, code block, and remote code files. CSP limits what code can be executed through an HTTP response header with a minimal policy configuration to prevent this.

Usage §

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header.

Block all script execution §

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

The header above only allows scripts to be loaded and executed from the same origin as itself. This prevents the execution of any malicious code regardless of its payload. Consider the following in-line code:

<img src="picture.png" onerror="evilFunction()">

Although this code is present on the page, the browser cannot verify its origin. The browser also knows that it was not loaded from the same origin as itself. Hence, it will not be executed.

While this is a relatively straightforward method, the prevention of all potentially harmful Javascript code can be incompatible with many applications, especially those that rely on in-line event handlers, such as onclick.

Use script hashes §

This method allows the execution of specified Javascript code. The CSP policy header enables the addition of the hash of a script block, as shown below:

Content-Security-Policy: script-src 'sha256-hashValue'

On the first page load, the browser calculates the hash of the script block and compares it to the hash in the CSP header. If it matches, the code is allowed to be executed. This is a safe way to ensure that legitimate code is loaded. However, it only approves a single block of code. Moreover, this method only works for in-line code and code blocks, not remote code files.

Use script nonces §

Similar to the previous method, this method includes the use of nonces, a random value, to allow the execution of a certain code, as shown below

Content-Security-Policy: script-src 'rand0mNumber123'

The CSP policy header is configured with a nonce attribute, which should match the nonce specified in the script block.

<script nonce="rand0mNumber123">
    // insert code here
</script>

Script nonces can be used for remote code files as well. However, to be effective, the nonce must be regenerated on each page load to prevent guessing by the attacker.

Bypassing in-line CSP §

It is possible to bypass CSP by allowing the execution of all in-line code. We do so by including the unsafe-inline value in the header, as shown below:

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

As a result, all in-line code, including malicious code, will be loaded and executed.

Examples §

Example 1 §

A website administrator wants all content to come from the site’s own origin (this excludes subdomains.)

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

Example 2 §

A website administrator wants to allow content from a trusted domain and all its subdomains (it doesn’t have to be the same domain that the CSP is set on.)

Content-Security-Policy: default-src 'self' example.com *.example.com

Example 3 §

A website administrator wants to allow users of a web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

Here, by default, content is only permitted from the document’s origin, with the following exceptions:

• Images may load from anywhere (note the ”*” wildcard).
• Media is only allowed from example.org and example.net (and not from subdomains of those sites).
• Executable script is only allowed from userscripts.example.com.

Example 4 §

A website administrator for an online banking site wants to ensure that all its content is loaded using TLS, in order to prevent attackers from eavesdropping on requests.

Content-Security-Policy: default-src https://onlinebanking.example.com

The server permits access only to documents being loaded specifically over HTTPS through the single origin onlinebanking.example.com.

Example 5 §

A website administrator of a web mail site wants to allow HTML in email, as well as images loaded from anywhere, but not JavaScript or other potentially dangerous content.

Content-Security-Policy: default-src 'self' *.example.com; img-src *

Note that this example doesn’t specify a script-src; with the example CSP, this site uses the setting specified by the default-src directive, which means that scripts can be loaded only from the originating server.

Reference §

Content Security Policy (CSP) - HTTP | MDN Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)  |  Articles  |  web.devEducative Answers - Trusted Answers to Developer Questions Defending against XSS with CSP Content Security Policy (CSP): Everything You Should Know