Increasing security for Single Page Applications
Gary Archer, Product marketing Engineer at Curity, gives us insights into User Experience (UX) and Security on web pages.
The internet age has ensured we are spoilt for choice with cutting-edge technology, web speed, and accessibility. With so many options available, fast and reliable web pages are expected for most users online. And why shouldn’t they be? If competitors can deliver a fast and responsive platform for users to access their products or services, then so can you.
Lagging web pages can be the source of mounting frustrations, customer dissatisfaction, a poor brand image, and for some, clicking off from the website altogether. The attention economy has made a frictionless online experience a requirement of modern internet usage. You can’t let your company fall at the first hurdle before customers have had a chance to look at what is on offer.
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 behavior and are responsible for improving UX. Using modern technologies such as React helps and leads to a good developer experience.
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. SPAs have played a pivotal role in improving the customer experience by ensuring that websites are highly responsive to end-user actions. 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 – 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 delivering 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 reasonably 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 do this, but using tokens in the browser is perceived as less secure. Tokens can be protected 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 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 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 similar to regular web apps without the need for a cumbersome backend to process it. This provides peace of mind while maintaining the all-important customer experience benefits that SPAs are cherished for. And the token handler approach is really flexible: implementation can be stateful or stateless, with the option of token handler components being deployed in different ways to suit individual websites.
Users will not accept sluggish web pages in this day and age. We have established that speed is super important in staying competitive online. However, it should never be prioritized ahead of security. When users entrust businesses with protected personal information, they expect their data to be protected in the best way possible. With no current method for browsers to store tokens securely, it is best for them to be left out of browsers altogether for the time being. Cookies and sessions must be brought back, but we must do this in a more dynamic way – which is precisely what the Token Handler Pattern brings to the table. Technology develops rapidly, but this is the best solution at our disposal until our browsers can become more secure.
Click here to discover more of our podcasts
For more news from Top Business Tech, don’t forget to subscribe to our daily bulletin!
Follow us on LinkedIn and Twitter
