Website security is essential these days. At a time where websites like Yahoo, DropBox etc. get hacked, people like me running small portfolio websites feel that their website is at far much danger of getting hacked.

In order to prevent websites against hacks and strengthening the security, there are a whole lot of options available.

One such option which I recently came to know about is Content Security policy. On knowing about this, I planned of implementing CSP on my website. But once I started with it, in few hours I realized I had to drop the plan and let it go.


What is Content Security Policy?

Content Security Policy or CSP is a way to set website headers such that the browser knows what should be loaded/executed and what not. This approach leads to prevention of XSS or Cross-Site Scripting Attacks on modern browsers by Hackers. One of the major benefits of implementing CSP is that it prevents execution of unsafe inline JavaScript.


How to Implement CSP?

CSP can be implemented in different ways, depending on the type of server you have or the language you are using for development. For sake of this post, I am using Apache as the server and all my CSP related settings would be applicable for .htaccess files.

.htaccess files are commonly used to put server level restrictions, redirections, compression or other similar settings on a website. One can use the same .htaccess file to set CSP headers for his website.

A simple example of implementing CSP in .htaccess on Apache server would be:

Headers Set Content-Security-Policy "default-src 'self'"

In the above piece of code, we are setting the CSP as follows:

  • We tell the browser to set Headers as per a Content Security Policy.
  • We define the CSP with a directive “default-src”. This specifies that would be the default source for loading any content on this website.
  • The directive value “self” specifies that all scripts and assets located on same domain as origin.


My Struggle for Implementing CSP and Why I Dropped the Idea?

I came to know about CSP when I ran a security check on my website using Mozilla’s Observatory Tool. This is a recently launched tool that checks your website for security loopholes.
On running the test on RJDesignz, I found that there were certain errors reported, the first one being related to CSP.

I started with fixing the security issues by browsing through the links shared on the results page and performing some google searches.

In order to find what all domains you need to allow, the best approach was to set the most simple policy in place:

Headers Set Content-Security-Policy "default-src 'self'"

The moment this was set and I refreshed the page, the website’s look and feel changed completely. The fonts didn’t render properly, slider was not working, widgets stopped showing, Google and Amazon ads stopped appearing etc.

On debugging the requests on Google Chrome’s Developer Interface, I found that a lot of scripts, font and CSS files were being blocked because of the newly implemented CSP.
I started checking all items one by one and added exceptions in the CSP.

After spending a good amount of time and adding initial level of exceptions, when I updated the .htaccess, I realized that new list of items were getting blocked. These were the ones which couldn’t be accessed earlier because the resourced didn’t execute earlier.

Then, on debugging each and every request again and again, I kept on adding more and more exceptions to the list. I was feeling a bit uncomfortable as well because if one needs to add so many exceptions, it would increase the header size, involve a lot of manual work and increase page load times as well.


Problem 1- Increased Header Size

My .htaccess file’s size increase by around 400 Bytes because of the new exceptions added, which meant the header size was quite big now.


Problem 2- Removing all Inline JS and CSS

Though I was able to make the website completely functional, I to know that there was a problem in the CSP settings and that was with the value- “unsafe-inline”. This value allows inline items to execute or load, but when I read about it in detail, it was something that was not recommended. Even Mozilla’s Observatory tool reported that. I was not happy with this because it meant that I had to move a whole lot of inline JS code into a separate JS file, which not only would have taken more time but would have lead to dependency issues because of the difference in order of loading.


Problem 3- Google Ads Won’t Display Correctly

Even though I could have done that, there was one more problem. This time it was with the Google AdSense code. Google ads are rendered on run-time and they could be region specific. So that meant, that even though the Google Ads were working fine for me, it might not be the case for other people who would be accessing my website.


Problem 4- Needs to be Updated Time and Again

I am running a WordPress based website and have several widgets included to show feed from Twitter and Instagram. In case the plugins get updated at some point of time or I need to add any other widget, the CSP would have to be updated yet again and all dependendencies of newly added plugin would have to be checked.
Seeing all these issues creeping in and after spending half of my day in setting the CSP headers, I finally decided to go away with the implementation of CSP headers on my website.

I know that my website might be exposed to some potential threats, but that would mean compromising with the look and feel and content on the website.