Security and frontend performance: Bridging the gap

How do you balance the speed of your site with effective security? Are the two goals fundamentally at odds? This episode of the O’Reilly Podcast features my discussion with Sabrina and Sonia Burney, Solutions Architects at Akamai and authors of the book Security and Frontend Performance. In this conversation we talk about how to balance the conflicting concerns of security and performance, and about some techniques for optimizing both.

How much do front-end developers really need to know about security?

Sonia Burney: It’s all related and interconnected. We as developers have to stop thinking that we exist in our own little bubble and realize that we fit into a larger system and workflow. It’s not that you need to know everything, but the basics are critical for success. Preventing simple attacks (like cross-site scripting or SQL injections or potential single point of failures) with different code and site structure changes can really benefit the overall end-user experience.

There are recent trends that developers should be aware of—in particular, third-party content and third-party attackers. If you don’t have different strategies for first-party versus third-party content, attackers can take advantage of that opportunity. Developers need to understand that any entry point, any resource download in a web site, can be a weak spot.

From one perspective, performance and security are at odds. It almost seems like a zero-sum game—if you increase the performance of your site do you have to make a sacrifice when it comes to security?

Sonia Burney: Security and performance have always been at odds. You often negate the benefits of one by focusing on the other. That said, we need to be sure that while we’re adding all these layers of protection, we are still doing this in an optimal way because that’s what our end users demand.

What are some techniques for optimizing website performance while maintaining security?

Sabrina Burney: A couple major techniques involve the HTTP/2 protocol and service workers. These are both technologies aimed at improving the end-user experience while also enforcing traffic over a secure connection.

There are also techniques for dealing with third-party content, which is a source of major vulnerabilities like having a single point of failure, or delivering compromised content to end users. We’re using techniques like the script tag. As developers we need to understand what types of risk are associated with those tags, and we need to look into using other techniques (like iframes) or a content security policy to help safeguard our sites using third-party content. This isn’t a complete list of techniques to use, but they are an important response to the problem of third-party content.

What are service workers and how do they help address performance and security concerns?

Sonia Burney: This has been a hot topic over the last couple of years, but you’d be surprised how many people still don’t really understand service workers or utilize them. At the end of the day service workers are just JavaScript that sits in between a site and the network, but it’s still at the browser. They’re workers working in the background.

They’re asynchronous in nature, with the capability to understand and then hijack incoming network resource requests and make a logical decision on whether to allow or deny that request to go forward to the network. In essence, this moves the backend logic to the browser.

In a performance sense, service workers allow you to control different third-party content and decide whether to allow or deny it based on performance factors: for example, how long it takes to download those third-party resources. You can then penalize a third-party domain for delivering content inefficiently to your site.

In a security sense, service workers can only be used over HTTPS. We’re essentially playing man in the middle, with the ability to intercept incoming network resource requests, so it’s important to make sure we’re only doing this over secure traffic. There are a few other caveats put in place to prevent further tampering of incoming requests. Another one prevents service workers from accessing the DOM so as to prevent manipulation of base page contents. Should the browser “detect” any potential harm a service worker could cause a site, it can terminate that service worker at any time.

What are some recommendations you have for developers who want to learn more about security?

Sabrina Burney: There are a lot of great resources out there (books and blogs) that provide a good intro on web security and how we address security concerns. For example, ModSecurity, WhiteHat Security, and MDN help with basic concepts when addressing security issues. As for blog posts on the latest news, check out Krebs and CVE.

Attending conferences is a great way to get started or to even get interested in the very idea of exploring web security.

One final tip for better understanding the security space is to work backwards. Look at security solutions that already exist today, get to know the type of attack factors that already exist, and go from there. That helps reinforce security concepts and is a great start for anyone who wants to get more involved in web security.

---

This post is part of a collaboration between Akamai and O’Reilly. See our statement of editorial independence.