How to Sleep Well Using Content Security Policies

Introduction

Web security occupies a peculiar place in our consciousness. One minute you’re worried about something like Heartbleed compromising your holiday photos, and the next you’re entertained by the antics of hackers targeting public figures. The reality is that web interactions are only as secure as their weakest point. To secure your website, you must also secure your customers. While it’s wise to stay current with web server encryption products, it’s important not to forget that a customer’s browser is an extension of your technical landscape, with all the lawlessness of the OK Corral.

The Importance of Content Security Policies

Symantec estimates that 73% of browser-based attacks come from the proxies customers use 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 website.

The good news is you can combat this with a Content Security Policy (CSP). A CSP uses standard HTTP headers to control how content is loaded on your pages, where it’s loaded from, and what it can do.

Benefits of a CSP

A CSP can lock down all the important assets on your production website, including JavaScripts, stylesheets, dynamic connectivity (Ajax, WebSockets), iframes, images, web fonts, video and audio sources, embedded elements, applets, and plug-ins. You can adjust policies by site area, such as securing applications like payment systems or file-transfer systems, to prevent any non-authorised code from running in a customer’s browser. You can even instruct the browser to send violation reports when errant scripts attempt to run, allowing you to analyse unprotected parts of your site to understand what’s happening.

Implementing a CSP

Implementing a CSP is straightforward:

Remove in-page coding: Rely on SCRIPT tags instead.

Specify script sources: Allow only specified domains (e.g., javascripts.example.com) and disallow all others.

Minimise third-party scripts: Host them on your own site if possible.

Be strict: Deny everything initially, then only allow what is necessary.

Log bypass attempts: Allow trusted assets while monitoring untrusted activity.

Balancing Strictness with Functionality

Of course, setting a CSP to block everything except assets on your domain can break your site. The web is interconnected, and many tools and assets on your site are sourced from partner domains. A strict CSP would block these, impacting analytics, CDN-loaded scripts, social/sharing buttons, developer tools, and browser extensions.

Support for CSP varies among browsers. You can check the full list of browsers and their support on caniuse.com. Internet Explorer, predictably, lags behind. The solution is to conditionally include or exclude your policies on the server side, based on the user-agent, until support becomes standardised.

Practical Tips for CSP Implementation

Scripts on a secure CDN: Ensure they are within a single domain.

Whitelist browser extensions: Permit only specified URI extensions.

Avoid iframes: They are risky as their content cannot be policed.

Selective script inclusion: Include social sharing and analytics scripts only when necessary.

Constant review: Regularly update permitted assets, denying access to defunct domains and scripts.

Conclusion

A CSP is not a silver bullet, but it helps you understand your cross-origin site activity and proactively address it. Whether CSP is right for you depends on your environment. Adopting a Content Security Policy requires an in-depth analysis of all website sources, a healthy practice to identify suboptimal practices like iframes and inline code. For large sites, it may not be cost-effective, but for new and smaller sites, it’s a valuable consideration. Strengthening each site fortifies the web as a whole, letting us sleep easier knowing our private business remains private.