Content Security Policy (CSP) (https://developer.mozilla.org/en-US/docs/Web/HTTP/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. These attacks are used for everything from data theft to site defacement or distribution of malware.

A proper CSP setup in your application can handle content injection vulnerabilities, and is a great way to reduce XSS. XSS stands at number two in the OWASP Top 10.

A CSP is not a solution to handling all injection vulnerabilities, but can be used as one of the tools to reduce injection attacks to a reasonable level.

CSP is a declarative policy, implemented using HTTP headers. It can be run in an application in two modes:

• Production mode (declared as CSP)
• Report-only mode (used for testing and are declared as Content-Security-Policy-Report-Only)

CSP contains a set of security policy directives responsible for putting appropriate restrictions on a web resource and then informing the client (user agent) accordingly when breached. For example, the following security policy snippet loads scripts from the defined trusted domains:

Content-Security-Policy: script-src https://trusted-domain.com

If there's a breach, the user agent will block it, and if the policy specifies a report-uri parameter, as shown in the following example, it will report the violation in the form of JSON to that URI:

Content-Security-Policy: script-src https://trusted-domain.com; report-uri /csp-report-api/

The previous examples showcase CSP working in production mode. If you would like to first test the security policy and after a particular period of time make those policies in production mode, CSP provides a mechanism for that, as shown in the following code snippet:

Content-Security-Policy-Report-Only: script-src https://trusted-domain.com; report-uri /csp-report-api/

In report-only mode, when a breach is detected, the report is posted to the report-uri in JSON format, as shown in the following code:

{"csp-report":
    {"document-uri":"...",
    "violated-directive":"script-src https://trusted-domain.com",
    "original-policy":"...",
    "blocked-uri":"https://untrusted-domain.com"}
}

Apart from the security directives detailed in the preceding examples, there are a number of security directives that can be used while setting up your CSP. For a full list of directives, please refer to https://content-security-policy.com/.

In a similar way to CSRF tokens, CSP can also be used to make sure that specific resources contain a token while accessing the server. The following example shows the use of this nonce approach:

Content-Security-Policy: script-src 'self' 'nonce-<cryptographically generated random string>'

Similar to a CSRF token, this nonce has to be included along with any resource access in the server, and this has to be newly generated while a page is loaded.

CSP also allows you to load the resources only if they match the hash that the server expects. The following policy is used to achieve this:

Content-Security-Policy: script-src 'self' 'sha256-<base64 encoded hash>'

CSP is supported by almost all modern browsers. Even if some security directives are not supported by certain browsers, other supported directives will work without any problem. The best way to handle that is to send only the security directives that will definitely be supported by the browser by deciphering the user agent, rather than throwing errors on the client.