Web security inhabits in a weird place in our consciousness. One minute you’re worrying because something called heartbleed could have allowed hackers to access pictures of you partially-clad on a beach holiday, and the next you’re enjoying the antics of those mysterious people in Guy Fawkes masks doing the same to self-righteous public figures. Web interactions are generally only as secure as their weakest point.If you want to secure your web site you also have to secure your customers. Whilst it’s wise to stay current in the continuous arms race of web server encryption products, it’s important not to forget that a customer’s browser is an extension of your technical landscape, an extension with all the lawlessness of the OK Corral.
Symantec estimate that 73% of browser based attacks came from the proxies that customers were using to access websites. In 2007 they reported that 84% of web security vulnerabilities were due to cross-site scripting attacks (unauthorised code running in a customer’s browser compromising both them and the intended web site).The good news is you can do something about this using a Content Security Policy (CSP). A CSP works via standard HTTP headers which allow website owners to control how the content is loaded on their pages, where content is loaded from, and what that content can do.

A CSP can lock down all the important assets on your production web site, including: JavaScripts, stylesheets, dynamic connectivity (ajax, web sockets), iframes, images, web fonts, video and audio sources, embedded elements, applets and plug-ins.It’s also possible to adjust policies by site area. For example, if you run a secure application such as a payment system, or secure file-transfer system, you will want to prevent any code that’s not yours running within a customer’s browser. This includes curious developers poking around with debugging tools. You can even instruct the browser to post your violation reports when errant scripts attempt to run, which means you can analyse even unprotected parts of your site to see just what is happening out there.

Be strict with your CSP…but not too much

Implementing a CSP is quite straightforward:

  • Remove in-page coding, instead rely on SCRIPT tags
  • Specify from where your scripts may be loaded
  • Allow only these domains (e.g. javascripts.example.com) and disallow all other domains
  • Minimise reliance on third-party scripts, hosting them on your own site if possible
  • Be strict. Deny everything to begin with and then only allow what is needed
  • Log all bypass attempts so you can allow trusted assets whilst monitoring untrusted activity.

Of course there are always downsides. If you were to set your content security policy to block everything except those assets on your own domain your site will likely cease to work. The web is an interconnected ecosystem. Most of us forget that large parts of our sites, and the tools we use on them, are actually sourced from partner domains via various mechanisms. By default, a strict CSP would block these. A few things that would break include: analytics, scripts loaded from a content delivery network (CDN), social/sharing buttons, developer tools and many browser extensions.The other problem with CSP is support. Honouring the HTTP headers that enforce content security requires a compliant browser. You can see a full list of browsers and their support at caniuse.com. Predictably, Internet Explorer support lags behind the others.The solution to browser support is the same as for most cross-device features – conditionally include or exclude your policies on the server side, using the user-agent, as the page is being built, until support is more standardised.

image

 

Unfortunately there is no real way to secure older versions of Internet Explorer other than deny access to the site. Where cross-domain assets are required for the site to function here are a few items to check.
A CSP is not a silver bullet, but they are a mechanism to better understand your cross-origin site activity and to proactively do something about it.Whether CSP is the right solution for you depends on the environment that you are planning to apply it to. To adopt a Content Security Policy, an in depth analysis of all web site sources must be conducted. Though tedious, it is a healthy activity and one that should be performed regularly anyway – if only to identify and highlight use of suboptimal practices like iframes and inline code.For very large sites it may not be cost-effective to implement a CSP policy, but for new and smaller sites it is certainly something to actively consider, especially as it prevents your domain being used as the inception point for an attack on someone else’s site. The stronger each site is, the stronger the web is as a whole, and the easier we can sleep, knowing our private business remains just that.

  • Scripts should be on a secure content delivery network (CDN) within a single domain
  • Browser extensions permitted should be whitelisted by URI. All others denied.
  • Iframes are inherently dangerous as there is no way to police their content. Try to remove them altogether.
  • Include script sources for social sharing and analytics on an as-needed basis and only when necessary.
  • Constantly review permitted assets, denying access to defunct domains and scripts as soon as they cease to be required.

A CSP is not a silver bullet, but they are a mechanism to better understand your cross-origin site activity and to proactively do something about it. Whether CSP is the right solution for you depends on the environment that you are planning to apply it to. To adopt a Content Security Policy, an in depth analysis of all web site sources must be conducted. Though tedious, it is a healthy activity and one that should be performed regularly anyway – if only to identify and highlight use of suboptimal practices like iframes and inline code.For very large sites it may not be cost-effective to implement a CSP policy, but for new and smaller sites it is certainly something to actively consider, especially as it prevents your domain being used as the inception point for an attack on someone else’s site. The stronger each site is, the stronger the web is as a whole, and the easier we can sleep, knowing our private business remains just that.