Latest News

Increasing security for Single Page Applications

Written by Gary Archer, product marketing engineer at Curity

In this digital age a website that loads slowly is one of the main factors that significantly increases user bounce rate. A fast website streamlines the browsing process ensuring a better overall experience. Companies spend a lot of time and money getting the competitive edge of user attention. However, we all know it takes very little as a user to click away and use another site or service if it proves to be more responsive and readily available. Not taking the loading times of a website seriously can reduce page views, conversion rates and most importantly potential revenue.

Single Page Applications (SPAs) have become the most popular way to create websites that feel faster for the end-user without hitting the server every time a user interacts with an application. The speed of a website is part of the best User Experience (UX). Developers have control over browser behaviour and are responsible for improving UX. Using modern technologies such as React helps and leads to a good developer experience. Moving away from the traditional cookie-based approach, SPAs have no dedicated backend and instead use access tokens to call APIs on behalf of an authenticated user and return the relevant data. By ensuring that websites are highly responsive to end-user actions, SPAs have played a vital role in improving the customer experience. However, the shift from handling authorisation with cookies to access tokens can have a severe impact on security.

First and foremost, the frontend code operates in an insecure environment: a user’s browser. SPAs often possess a refresh token that grants offline access to a user’s resources and can obtain new access tokens without interaction from the user. As these credentials are readable by the SPA, they are vulnerable to Cross-Site Scripting (XSS) attacks, which can have dangerous repercussions – with attackers gaining access to users’ personal data and functionalities not normally accessible through the user interface. As the online data pool grows and hackers become more sophisticated, security must be taken seriously to protect customers’ information and businesses’ reputations.

However, designing security solutions for SPAs is no easy feat. As well as the strongest browser security and simple and reliable code, software developers must consider how to deliver the best user experience – wrapping all this into a solution that can be deployed anywhere. The SPA’s web content can be deployed to many global locations via a Content Delivery Network (CDN). Web content is then fairly close geographically to all users so that web downloads are faster.

The current best practice is for SPAs to protect tokens from malicious code. There are other ways to protect tokens, but using tokens in the browser is perceived as less secure. Protecting tokens can be achieved by adding a backend component to handle tokens and issue secure cookies to the frontend – often referred to as a Backend for Frontend (BFF) approach. Many developers use website stacks with a ‘web backend’ that both serves static content and also writes secure cookies – which, in principle, solves the security problem. However, website stacks simply aren’t designed for the separation of Web and API concerns that SPAs are characterised by.

The Token Handler Pattern is a modern evolution of BFF, where OpenID Connect security is implemented in an API-driven manner. Using this approach, all communication from the SPA to the Authorisation Server goes through the Token Handler. This eliminates the need for tokens to reach the SPA, with the Token Handler instead issuing session cookies to the SPA. The cookies are used during requests to APIs and are exchanged for an access token, preferably by a dedicated plugin in the API gateway, so that the API code is kept simple. As the Token Handler code is not available in the browser, it can act as a confidential client for the SPA, further increasing the security of token issuance.

The result? The Token Handler Pattern provides SPAs with a level of security like regular web apps without the need for an unwieldy backend to process it. This provides peace of mind whilst preserving the essential customer experience benefits that SPAs are respected for. And the Token Handler approach is flexible: implementation can be stateful or stateless, with the option of Token Handler components being deployed in different ways to suit individual websites.

A slow-moving website may have been tolerable previously. But to stand the test of time, performance and security should be two of the essential metrics to focus on for business success online. It is worth mentioning that these two metrics should complement each other and should never be used interchangeably.  A slow website means a loss of potential revenue and low search engine rankings, whereas an unsecure website gives hackers an opportunity to exploit and take down websites for reputational and business loss.

Considering that browsers are unable to securely store tokens, it is wiser to keep them out of the browser altogether until further notice. This implies returning back to sessions and cookies but doing so in a more effective way – which is by and large what the Token Handler Pattern offers. Until we get to a stage where browsers become more secure, there is no doubt in my mind that this solution is the best arrangement we have for security and efficiency.