Fast and safe frontend fixes

Security and Performance are both considered to be two separate goals, as one can often negatively impact the other. We see various security solutions — whether implemented at the frontend or backend — slowing down the performance of sites. And vice versa: we see certain performance techniques leaving sites more vulnerable to security threats. In the face of these challenges we need to make sure that our sites are adapting to the needs of the customers.

Every year, we see an increase in security attacks in many different areas (for example, in finance and healthcare) and we can only expect this rise in threats to continue with the Internet of Things (IoT). This increase is can be attributed to an escalation in web traffic, with resulting high volume/high load situations which motivate us to more closely focus on performance. It is also due to the growth in the number of third party resources being leveraged on sites today — not only do they introduce potential security holes such as delivering malware and/or malicious code from third party attackers, but they can slow down the site and delay content parsing/loading.

So how can we bridge the gap between security and performance? We need to shift the focus from what we can do from a server or platform level to what we can do from a frontend perspective. In other words, we need to shift the focus to the browser and leverage certain frontend techniques to provide both an optimal and secure end user experience.

What are some of the frontend techniques we can use to optimize and secure the end user experience?

Let’s briefly look at some of the different options.

Quick wins!

A few quick and easy solutions to achieving a secure and optimal experience can be implemented using frontend techniques like HTTP Strict Transport Security, Content Security Policy, and iFrames.

• HTTP Strict Transport Security (also known as HSTS) is essentially a response header indicating that a browser enforces a secure connection over HTTPs to a particular domain/subdomain. By using this, we not only can avoid man-in-the-middle (MITM) attacks, but we remove the need to perform HTTP->HTTPs 301/302 redirects during an end user’s session. Instead, the HSTS technique results in the browser performing an internal redirect which reduces the overall number of outgoing requests to a CDN or origin infrastructure.
• Content Security Policy (also known as CSP) is a policy where you can whitelist vendor or third party domains that can execute content on your site. With the growing popularity in third party content, we observe a rise in third party attackers where security incidents can indirectly result in performance issues. That being said, a third-party resource can result in a single point of failure (SPOF) as a result of a security attack on a vendor. Using the CSP solution secures sites and can prevent SPOFs from unknown or compromised third party content.
• iFrames is a concept that has been around for quite some time, however, they’ve been updated with new techniques like sandbox, srcodc, and referrerpolicies that can help the growing need to secure and optimize. These more recent techniques can provide a way to secure sites from compromised third party content (sandbox and srcdoc), and provide an additional layer of security in the form of privacy (referrerpolicies).

Hide your content

As mentioned, third party content is on the rise, and with that, we are exposed to third party attackers. To avoid these attackers learning first party vendor usage, we can use a technique called obfuscation. Obfuscation is known to be a method in hiding or hashing resources like JavaScript objects to avoid malicious end users from reverse engineering server side logic. Generally speaking, security through obfuscation is not perfect, as it can be compromised. Instead of using this technique as a single solution to secure infrastructures, obfuscation should really only be used on top of existing security measures in place.

Keeping in mind that obfuscation can provide an additional security layer, we are proposing obfuscating third party domains in a first party site — that way we can hide information that exposes our vendors to third party attackers. There are several methods in accomplishing this, for example, using apache rewrite module, varnish, or CDN capabilities to rewrite these third-party URLs into an obfuscated manner and translate them when content must be fetched. Using this method, we can avoid both security or performance incidents that are caused by third party attackers — including situations like a single point of failure.

Service workers to the rescue!

One of the more popularly known technologies now, yet still not in widespread use, is service workers. Service workers are essentially client side JavaScript, acting similarly to a shared worker, and sit between the site and the network. They also act as proxies for incoming network resource requests.

There are numerous uses for service workers, including:

• Tracking performance metrics of third party content
• Controlling the delivery of that third-party content based on reputation (as determined by what we define as the measurement strategy).

We can leverage service workers to monitor the performance of certain third party resources (maybe known to cause poor site performance), keep track of how that third party content is acting over time, and then perhaps block/redirect that request or serve a response from cache. Service workers give us the ability to optimize both performance and security through monitoring and taking action so we can provide that expected end user experience.

Conclusion

With any of these frontend solutions in place, we can drastically change the way we handle content, providing that fast-yet-secure experience that our users expect. These solutions also provide for out of the box use cases because they are very flexible in design implementation. It’s up to you to decide how to bridge the gap between performance and security, either by leveraging new technologies, or even combinations of the above solutions. A key takeaway from this is that a performance solution can be a security solution in disguise and vice versa.

---

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