Add Content Security Policy (CSP) Header in Nginx With report-uri

In the previous guide, we talked about how to around HTTP Public Key Pinning (HPKP) Nginx With report-uri. Content Security Policy (CSP) header adds control over the resources to be loaded on modern browsers to increase security. Here is How to Add Content Security Policy Header in Nginx.

What is Content Security Policy (CSP) Header? Why We Need CSP?

As like the most current recommendations and Standards related to frontend security, Content Security Policy (CSP) is for HTTPS website. That should not be a concern anymore as Let’s Encrypt provides forever free SSL certificates and no longer inferior choice compared to the paid DV SSL certificates.

With the Content Security Policy (CSP) Header, web site administrators can use combination of directives that can be used to suit their web site’s needs. Content source is a string which indicates a possible source from which content or type allowed to be loaded. Source list is a string specifying Internet hosts by domain name (read FQDN) or IP address, URL scheme and/or port number. There is also optional report-uri used for CSP violation reports. The report-uri must be of different FQDN than that of the applied policy. Content Security Policy (CSP) specification is currently of version 2 (at the time of writing this guide) and W3C Candidate Recommendation, dated 21st July 2015.

Most of the blogging softwares like WordPress or content management system like Drupal, Joomla! needs Content Security Policy (CSP) Header as their backend is either LAMP server or LEMP server i.e. uses PHP as dynamic programming language and has a database. PHP and MySQL combination, unlike plain static HTML serving websites has vulnerabilities. It is not difficult to get access via PHP shell by the script kiddies. Technically risk increases when there is self hosted web form on a webpage. Ping, Trackback etc also increases risk. Obviously, the forum softwares also need Content Security Policy (CSP) Header. Content Security Policy (CSP) Header can decrease the chance of Javascript malware, XSS attacks to mention few of its original target.

However, Content Security Policy (CSP) Header is highly restrictive. Without proper understanding and testing, websites with Google AdSense Ads may end up getting all the Ads blocked. CORS header itself restrictive.

How To Add Content Security Policy (CSP) Header in Nginx With report-uri?

This is an example header output upon running curl -I followed by domain name :

to get the above response, we need to add the following to /etc/nginx/sites-available/default website configuration file or any modified named file in /etc/nginx/sites-available/ directory :

Note that ;"; ending. First semi-colon is for Content Security Policy (CSP), second is for Nginx. Also, website name is not enclosed inside ' '.

Reporting URI can be used with a free service like that report-uri.io as like described in our other similar topic – HTTP Public Key Pinning (HPKP) Nginx With report-uri.

Content Security Policy Example

The Content Security Policy header value is made up of one or more directives. Below are the authoritative source of Content Security Policy (CSP) directives :

The interesting directives which are holding promise for higher security on client side are –

upgrade-insecure-requests directive instructs user agents to automatically upgrade all insecure resource requests from their pages to secure variants. The URL will be rewritten before the request is made, meaning that no insecure requests will hit the network. Example :

This is a bigger topic :

report-uri directive instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI.

‘unsafe-eval’ allows the use of eval() and similar methods for creating code from strings. This must be used after understanding the legit Javascripts. In other words we do not recommend blindly add it.

reflected-xss directive instructs the user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks with any of the values – allow, block, filter. Allow is expected for co-operation.