Increasing security for single page applications (SPAs)

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.

Shifting 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 pivotal role in improving the customer experience. However, the shift from handling authorization with cookies to access tokens has severe security implications.

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 such as 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 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 characterized 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 authorization 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 similar to regular web apps, but without the need for a cumbersome backend to process it. This provides peace of mind whilst maintaining the all-important customer experience benefits that SPAs are cherished 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.

Once the norm, tardy websites are inexcusable today. But in the race to capture consumer attention, speed shouldn’t come at the cost of security. If businesses fail to adequately protect their website users’ data, a lot more than attention is at stake.

Given that browsers currently have no way of securely storing tokens, it is better to keep them out of the browser altogether for now. This means reverting to sessions and cookies but doing so in a more dynamic way – which is exactly what the token handler pattern brings to the table. Until browsers become more secure, I can confidently say that this is the best solution that we’ve got.