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 owner/administrator of the website to reduce or eliminate the probability of an attacker triggering an XSS attack. It will specify which domains are safe and legitimate.

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

Essentially CSP allows the admin to be explicit about what resources should be trusted. 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 they can be set on the web server or set as required. 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. There are plenty of CSP packages available in any programming language.

The following code is an example of setting up a CSP header using a package for Javascript.

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 takes all inline scripts to be harmful.

Content Security Policy presents some advantageous key features, mainly about preventing code injection, clickjacking, and other client-side vulnerabilities.

Reporting is also a common tool to be used as a way to monitor potential vulnerabilities and report violations of the policy.

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, resulting in the applications still being 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 some reduced flexibility - CSP can block a script from being loaded but is limited in the ability to block only specific behaviors of the script, for example, 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.

When it comes to PCI DSS v4 compliance, the CSP is mentioned by the PCI Security Standards Council as suitable to meet the 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 it is impossible to meet all the demands of the two requirements with just CSP and/or SRI.

The additional work is necessary to meet the requirements and can result in significant operational efforts. 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 have to be verified for the potential presence of skimming code, which CSP or SRI on their own do not provide. Finally, monitoring HTTP headers necessitates separate systems.