Content Security Policy
A few weeks ago I was doing some research into web application security to placate some security concerns a security audit raised. For the most part what I found was the typical advice
- Avoid SQL injection attacks by using parameterized queries
- Use low privilege accounts to run the web server and the database
- Don’t connect to the SQL server with an account with permissions other than db_reader and db_writer(or your database’sequivalent)
- Validate user input
- HTML encode any untrusted string(so pretty much everything)
- Avoid using dynamic SQL
Onerelativelynew development I hadn’t heard of was using a technique called Content Security Policy. To understand the purpose of CSP you first need to know a little bit about what comes down the line to you from the web server and how the browser handles it.
To get this working you’re going to need to add 3 different headers to your site. This is because the various browsers have differing levels of support for CSP.
The first line is the policy as defined by the W3 standard, it is supported only by chrome and even then only by version 25+. The second version works in older WebKit based browsers. The third is supported by FireFox and IE10+. The support for CSP across browsers is not fantastic. At the time of writing there is support for about 55% of users.
There are quite a few rules you can use in the CSP. The rules above require that all your scripts come from your domain. If you make use of a CDN then you can add it to the end of the rules
You can also set the default so that all resources (scripts, style, images, flash, frames, fonts) are restricted to your server.