How to Harden Your eCommerce Solution Security Defenses with the Help of HTTP Security Headers: Content Security Policy

Our first article in this two-part series, A Comprehensive Look at How to Harden Your eCommerce Solution Security Defenses with the Help of HTTP Security Headers, focused on four specific Security Headers. We have one more for you today: Content Security Policy. Content Security Policy, commonly known as CSP, requires both careful tuning and a definition of policy. If enabled, CSP may have a significant impact on the way a browser renders web pages. For example, inline JavaScript is disabled by default; it must be explicitly allowed by the policy. CSP also prevents a wide range of major attacks such as cross-site scripting, clickjacking, and other cross-site injections. CSP can replace most security headers, even the four we covered in our first blog post.

Because CSP is able to block most common attacks, it would stand to reason it’s widely used by its adoring fanbase. However, in reality, less than 6% of the most popular websites utilize CSP, according to data from Alexa. CSP is not the Bell of the Security Headers Ball because it’s quite difficult to implement.

Screen Shot 2021-06-15 at 4.58.26 PM.png

CSP is considered inconvenient to implement because it contains an access of 30 directives, with half of them being experimental. Some of the directives interfere with one another, and sometimes, proper usage of CSP would require you to entirely rebuild your web application. Furthermore, improper implementation of CSP can actually enable bad actors to break into your web application.

In case you do want to implement CSP, we recommend:

Do not start with Content - Security - Policy

Start with Content-Security-Policy-Report-Only; default-src ‘none’; form-action ‘none’; frame-ancestors ‘none.”

This action will create a report on what would occur if you blocked absolutely everything. Once you receive this report, you can handpick which items you wish to allow, which items need to create alternate fixes, and which items you want to block. If you did not set the CSP into report only mode, you would experience the full blast of CSP. It would literally block most of your app, and your website would stop working entirely. When you implement CSP in report-only, and then open your console and browser tools, you will typically see a list of errors. Most errors should begin with “report-only;” this conveys which content will be blocked and how to allow it. In order to fix the style error, you will need to adjust the security policy, body, and style directive, and add “self;” adding “self” will allow you to include any TSS style sheet hosted on the same URL and the same port number as your page. The same goes for your images and scripts. In case you do not need to demarcate these items, you can up the “default,” and it will automatically allow all content which is placed on the same URL and port number.

Screen Shot 2021-06-15 at 5.11.25 PM.png
Screen Shot 2021-06-15 at 5.12.41 PM.png

Next up, we will consider an inline script. Inline JavaScript is often used on websites, but they are considered quite unsafe, because they provide an easy way for bad actors to exercise attacks against your app. To allow script, you need to “unsafe-inline;” adding this to the CSP will directly allow bad actors to carry out attacks, so it is not advised.

To securely allow inline script, we have two secure approaches to share with you.

First, procure a hash of the script you want to allow and add it to the CSP. The second approach entails generating a unique line for inline script, so each user will be generated as a unique visitor. This can be added to the CSP in the same manner in which a hash can be added. It’s rare to see this second approach in the wild, as it’s quite inconvenient to implement.

Screen Shot 2021-06-15 at 5.18.46 PM.png
Where and How to Locate CSP Errors

One can locate CSP errors by using browser developer tools, or by viewing simulations of the CSP. It’s more convenient to use a report URI, which can be the same URI as your web application. It’s also possible to use third party providers for locating CSP errors. They allow you to automatically collect reports and violations of your CSP. Based on this information, they can generate a CSP directive for you, and you can make changes to your directives as well. Alternatively, you can use your own end point where you are able to collect these violations using a script, and using this, form your own CSP.

Screen Shot 2021-06-15 at 5.20.41 PM.png

Once you are satisfied with your findings from using report-only mode, your reports show up to your URI, and your web application works without errors, it’s time to activate your CSP.

Remember, having a CSP with a few unsafe rules is still much better than not having a CSP at all. As a note, the “almost strictest CSP directive” is best used by websites with large legacy rules that need to be upgraded to higher security standards.

Screen Shot 2021-06-15 at 5.22.59 PM.png

To conclude, there’s no one approach that will work best for all web applications. Each approach should be tailored according to your architecture and site needs. Use caution when implementing CSP, and consider it at the very beginning of your project. It is much easier to implement right at the start, instead of trying to make it fit an existing web application.

If you want to check the current security headers on your project, check out securityheaders.com to find out about the best practice for security headers. If you want to upgrade your headers, implement a new header, or understand the drawbacks behind a specific header, you can use CSP-Evaluator with Google. If you use the short version of this tool, you can actually check the CSP of major websites such as Netflix. This tool reveals that even major players don’t always abide by best security practices, mostly because of difficulties with implementation.

Curious about implementing better security practices? Check out our services, tools, and resources, and get in touch with us today!