What is Content Security Policy (CSP)?

Reading time: 5 minutes

The web’s security model is rooted in the same origin policy. Code from a site (say https://iq.opengenus.org should only have access to https://iq.opengenus.org ’s data, and any other site should never be allowed access. Cross-site scripting (XSS) attacks, for example, bypass the same origin policy by tricking a site into delivering malicious code along with the intended content. This is a huge problem, as browsers trust all of the code that shows up on a page as being legitimately part of that page’s security origin.

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 that can be carried out on web applications. These attacks are used for everything from data theft to site defacement to distribution of malware. It does this by selectively specifying which content should be loaded in web applications.

As we all know, HTTP is based on the client-server architecture model and a stateless request/response protocol that operates by exchanging messages across a reliable TCP/IP connection. Every time you click to view any resource on a web application a request for that resource is sent to the web server and if the resource exists and all conditions (including authentication, access contols etc) are met then the server issues a response messsage to the client.

These messages are requests from client to server and responses from server to the client. Now, these messages will have certain HTTP headers that specify certain values like:

• the host (a third piece of information that you can use in addition to the IP address and port number to uniquely identify a Web domain )
• referrer (which url is requesting the resource)
• user-agent (a string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent.), etc.

Content Security Policy is a HTTP response header.

An example of a HTTP request for the discourse.opengenus.org page

Working

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore).

Alternatively, the meta element can be used to configure a policy, for example:

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self'; img-src https://*; child-src 'none';">

As a developer you can specify the Content Security Policy through a HTTP response header called Content-Security-Policy.Then a web browser that supports CSP, such as Chrome or Firefox, parses the header information and determines which sources are trusted or not based on the instruction sent in the header.

Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control resources the user agent is allowed to load for that page. For example, a page that uploads and displays images could allow images from anywhere, but restrict a form action to a specific endpoint.

You can use the Content-Security-Policy HTTP header to specify your policy, like this:

Content-Security-Policy: policy

A policy is described using a series of policy directives, each of which describes the policy for a certain resource type or policy area. Your policy should include a 'default-src' policy directive, which is a fallback for other resource types when they don't have policies of their own. (view the complete list here)

Check the examples out to get a better understanding.

Examples

Example 1

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

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

'self' refers to the origin from which the protected document is being served, including the same URL scheme and port number.

Example 2

A web site 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' *.trusted.com

The * in *.trusted.com covers all possible subdomains of a website trusted.com (abc.trusted.com, def.trusted.com, etc.)

Example 3

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

Content-Security-Policy: default-src 'self' ; 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.

Application

The primary benefit of CSP is preventing the exploitation of cross-site scripting vulnerabilities. When an application uses a strict policy, an attacker who finds an XSS bug will no longer be able to force the browser to execute malicious scripts on the page.

CSP is recommended for applications which manage sensitive data such as administrative UIs and device management consoles, or products hosting user-generated documents, messages or media files.