Content Security Policy (CSP) Header

Overview

Content-Security-Policy is an HTTP Response Header that is returned from a website to prevent cross site scripting(XSS) and click jacking attacks. These headers are custom headers that can be added by any server side programming logic or it can be added by the web server if it is configured to do so.
When any web application is developed for public access it is prone to attacks from the hackers to steal information or run malicious code to take control of our application. It is therefore very necessary to protect our application from vulnerabilities like cross site scripting and click jacking.
While working on a web application it is quite common that we get recommendation from the VAPT(Vulnerabiltiy Assessment and Penetration Testing) report that we need to have content security policy headers passed in the response to prevent our application from attacks. The web application does not usually get sign off for production deployment without having a strict content-security-policy in place.

Understanding the vulnerabilities

When a web application runs in a browser it uses session cookies and other important user specific information in the browser.
Due to the same-origin-policy of the web browser any other page of the web application is granted permission to access the session cookies and other information in the web browser, however these information are not accessible by any other web application running on the same browser on a different origin.
Attackers usually inject client side code into the response being generated by the browser and that code looks like it is executing from the same origin and it gains access to the important information stored in cookies thus having the control of the web application on behalf of the user. This type of attack is referred to as cross site scripting(XSS) and it is one of the most common form of attacks on the websites or web application.
The content-security-policy response headers enforce restrictions on what resources like javascript , css or anything else is loaded by the web browser thereby enchancing the security of the web page in a web application.
Due to the implementation of a strict content-security-policy it becomes impossible for the attackers to inject client side code in the web application while the web page is loaded.

Implementing Content-Security-Policy

The Content-Security-Policy can be implemented in two ways.
** 1. Meta tag **
** 2. Http Response Header **

The Content-Security-Policy can be applied on the web application as a meta tag inside the head tag of the HTML as mentioned below -

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

The name of the header i.e "Content-Security-Policy" will be defined as a value of the http-equiv attribute of the meta tag while the actual policy to be enforced has to be mentioned as a value of the content attribute of the meta tag.

The meta tag is present inside the head tag inside HTML and the policy is applied only when the web page containing the meta tag is loaded.
While meta tag is one of the available options of implementing the "Content-Security-Policy" it is primarily implemented using the "Content-Security-Policy" Custom Response Header. The below mentioned code represents the config file in IIS implementing the Content-Security-Policy.

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Content-Security-Policy" value="default-src 'self';" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Structure of the Content-Security-Policy Response Header

The syntax for the specification of the CSP Header is -

Content-Security-Policy: <policy-directive>; <policy-directive>

The policy-directive consists of 'directive value;directive value;directive value;' . In the example config settings for IIS mentioned above the default-src is the directive name and 'self' is the value. We can specify multiple values for a directive like - none, self, unsafe-inline, unsafe-eval, https:, ws:, data:.

A sample CSP specified in the config would look like -

<add name="Content-Security-Policy" value="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline';connect-src 'self' ws:;img-src 'self' data:" />

The default-src acts as a fallback for other directives when a particular directive is not specified. Let us say if we do not have the script-src in the above configuration then the script loading would use the default-src 'self' as a fallback. The above configurations allows inline scripts, the use of eval and the script execution from the https within the same domain. The web application with the above configuration can also connect to URLs withing the same domain and also make connections to the websocket. The images to be loaded must be within the same domain and it could be loaded using the data: scheme.

You can refer to the official documentation of the different policy directives and their allowed values from here.

Practical Scenario

Let us consider that you have developed a web application but you are yet to implement the CSP for the web app and you are not sure which all policies you need to apply to your application and how implementing a policy would impact the functionality in your application. In such scenarios rather than specifying the "Content-Security-Policy" you can specify the header "Content-Security-Policy-Report-Only" along with the directive report-uri with the value as the endpoint url.
This would allow you to record all possible policy violations in a JSON file on the endpoint mentioned for report-uri. You can then continue rigorous testing of you application and monitor the reports generated. Once the testing is complete you can go through the report JSON file and implement proper Policies as applicable for your application. The "Content-Security-Policy-Report-Only" is an experimental way of knowing the policy you would want to have in your application and later on change the CSP to "Content-Security-Policy".
This is a very effective way of implementing CSP in web applications.

There is a big list of directives available in the CSP and it completely depends on the application owner to restrict certain resources and allow others by having a strong CSP preventing your application from the attackers.
It is better to fix the code rather than making the CSP flexible since it would lead to a less secure application. For example if your application is using eval() to execute javascript code as strings then having the directive 'unsafe-eval' would allow the application to use eval() in your application and this could be misused by the attackers to gain access to your application however sometimes if do get to see unsafe-eval implemented in a production application possibly because it would be difficult to change the code to remove the dependency with eval() but remember it is worth spending time and finding out alternatives than having your application vulnerable to attacks.

I hope you enjoyed reading this post and would have a strict CSP implemented for your application.
Thank you for reading and see you in the next post !