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 the functionality of a website.

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 CSP is supported by modern web browsers, older browsers may not fully support all directives. Additionally, some older versions of browsers may exhibit inconsistent behavior with certain directives.