Content Security Policy (CSP)

CSP exists as a security mechanism for web applications that helps detect and mitigate certain types of attacks, such as XSS attacks. This type of attack exploits the browser’s trust in the content received from a server.

A victim of an XSS attack is exposed to the execution of malicious scripts. Implementing CSP allows the website owner/administrator to reduce or eliminate the likelihood of an attacker triggering an XSS attack. It will specify which domains are safe and legitimate.

If a browser is CSP-compliant, it will run only scripts from source files retrieved from whitelisted domains, ignoring all others. Additionally, a browser can be told to load only certain protocols specified by the server.  For example, the server can determine that browsers can load content via HTTPS.

Essentially, CSP lets the admin be explicit about which resources to trust. Resources mean scripts, but also things like:

• stylesheets;
• media (for example audio and video);
• fonts;
• form actions;
• frame sources;
• types of objects and plugins.

In essence, what CSP provides is a means to “allowlist” the source of these resources. CSP is an important tool and should be used for any web application that manages sensitive data.

There are two ways to implement CSP:

• Via HTTP headers;
• Via meta tags in the HTML of the page.

HTTP headers are the recommended approach, and you can set them on the web server as needed. Adding the CSP HTTP header to a web page and giving it values controls what resources the user agent is allowed to load for that page. Plenty of CSP packages are available in any programming language.

The following code shows how to set up a CSP header using a JavaScript package.

var express = require(‘express’);

var app = express();

var csp = require(“simple-csp”);

var csp_headers = {

    “default-src”: [“‘self'”, “http://example.com”],

    “connect-src”: [“‘self'”, “http://example.com”],

    “img-src”: [“‘self'”, “data:”, “http://example.com”]

};

app.use(“/”, function(req, res, done) {

    csp.header(csp_headers, res);

    done();

});

// Static files from ./public

app.use(“/”, express.static(“./public”));

app.listen(8888);

It’s possible to specify what is to be trusted in different ways. These are just a few examples:

• Trust only scripts from the same source via HTTPS,
• Only allow images from a particular CDN
• Disallow frames
• Only allow fonts from Google Fonts

It’s important to note that CSP treats all inline scripts as harmful.

Content Security Policy offers several key advantages, mainly by preventing code injection, clickjacking, and other client-side vulnerabilities.

Reporting is also a common tool for monitoring potential vulnerabilities and reporting policy violations.

Granular control over resource loading: CSP offers fine-grained control over which content sources are allowed, allowing developers to specify different policies for different parts of a website or web application.

On the other hand, CSP is easy to misuse, and syntax mistakes are common since it is a manual tool. Some browsers work with it better than others, so applications can still be vulnerable to attacks. Regarding Management Complexity, managing CSP may require a thorough understanding of the application’s behavior and resource requirements. Incorrect configurations can break a website’s functionality.

CSP also has reduced flexibility: it can block a script from loading but can’t block only specific script behaviors, such as accessing data present on the page. Lastly, although modern web browsers support CSP, older browsers may not fully support all directives. Additionally, some older versions of browsers may exhibit inconsistent behavior with certain directives.

For PCI DSS v4 compliance, the PCI Security Standards Council mentions CSP as suitable for meeting requirements 6.4.3 and 11.6.1. It is mentioned together with SRI. SRI is a security feature that allows browsers to ensure that loaded resources (such as those from a third-party domain) have not been tampered with. It achieves this by enabling you to specify a cryptographic hash that the resource must match. The downside is that CSP and/or SRI alone cannot meet both requirements.

Meeting these requirements requires additional work and can create significant operational effort. These efforts include dealing with unmanageable report volumes(with dynamically changing third-party hosted scripts), manual documentation for authorized scripts, constant hash maintenance to avoid functionality breaks, etc. Moreover, scripts must be verified for potential skimming code, which CSP or SRI alone do not provide. Finally, monitoring HTTP headers necessitates separate systems.