LexBlog & Content Security Policy

Some years ago, I reconnected with a friend and fellow developer, Soren, who happens to work exclusively in the field of web security research: He’s a pen-tester. In other words, you pay him to break into your site to make sure no one can break into your site. Yes, this was also the plot of the excellent 90’s film, Sneakers:

As I came to know him and his work better, I grew curious about having him review our platform. I was not surprised to find that our platform got good marks on web application security. Though he noted that he’d like to see more customers opt for our two-factor authentication and country-based whitelisting products, he was impressed.

But his tests also covered a different category of security that I’ll refer to as HTTP. HTTP is the layer where your web browser interacts with our web servers, and you can read the HTTP data, or “headers”, in your browser’s network console:

Here’s the relevant portion in more detail:

Those pictures demonstrate the HTTP headers that our servers send to your web browser. They are an opportunity to provide a robust layer of security, and I was not fully taking advantage of it. In fact, according to Soren’s report, I was getting something like a C- or a D+!

This report shocked me. I felt very confident in my understanding of web application security (sanitizing and validating form submissions, say), but I had not paid much attention to HTTP security. His reports contained a lot of low-hanging fruit. After implementing several of the HTTP headers that had no impact at all on site functionality, we were into the C+ / B- range. There was more work to be done, but I left it alone for some time because it fell under the sub-category of what’s called Content Security Policy (CSP). Zero customers had ever expressed interest in CSP, it’s not entirely crucial to the mere act of reading a blog post and — most importantly — CSP is a very hard problem.

Content Security Policy: What is it?

CSP is an HTTP header. You can see it in the screenshots above. But it’s an especially powerful one. You can use it to whitelist potentially harmful assets like JavaScript, embedded media, and even CSS. In other words, you can tell the web browser only to load certain assets, if they mean certain standards that you define. Example policies:

• The only JavaScript it’s allowed to load is the JS file that comes from your website.
• Don’t allow embedded media unless it’s from YouTube or Twitter.
• Only load an iframe if it comes from your domain.

This is such an incredibly powerful scenario for site security that it nearly boggles the mind. Even if a hacker managed to inject malicious content into our database or file system, it would be completely ineffective for most forms of attacks because we are of course not including it on our whitelist.

I like to use a bank robber analogy. Let’s say a bank robber makes off the with bag of cash. That’s just step one. He still has to get the cash into a form where he can actually use it. Maybe that means removing the ink bomb, maybe that means laundering the money.

For a website hacker, getting the malicious content injected is step one — that’s the bank robbery. But thanks to our use of CSP, getting the content launched against users (the money laundering) is impossible.

Why is Content Security Policy a Hard Problem?

It would be simple enough to just whitelist absolutely nothing… But then your site would have:

• No images.
• No CSS.
• No JavaScript.
• No Nothing.

Clearly we do want some of that stuff, but it’s challenging on a large and diverse platform like LexBlog, where we aim to solve problems for such a wide audience, in the most scalable way we can. If we were too whitelist too aggressively, site functionality that our customers have come to expect just wouldn’t work.

Simplicity is the Key

Although we’ve been able to improve the entire LexBlog platform, our core offering for customers that demand strict CSP is all about simplicity. We’ve removed some dated features that were dragging on CSP, and re-written many others in a simpler, more CSP-compliant way. Simplicity tends to have a lot in common with speed, maintainability, beautiful design, and in this case, security. Thanks to our work in this area, the very blog you are currently reading scores an A+:

The report above comes from the excellent (and free!) Mozilla Observatory. For our customers that have more robust needs when it comes to branding (heavily custom designs making use of more layouts, more media, more JavaScript) an A- is well within reach.

It really is a challenging body of work to morph a platform into compliance with these emerging standards. I invite you with great delight to try running a scan against your favorite law firm corporate website.