Single-Page Applications (SPAs) Security Doesn’t Work the Same as Websites

Single-page applications (SPAs) are rapidly gaining a stronger foothold as an easy-to-develop interface for digital data delivery and customer engagement.

Single-page applications (SPAs) are becoming increasingly popular due to their ease of development and ability to provide an engaging user experience. However, SPAs also come with unique security challenges. In this article, we will explore the difficulties of securing SPAs and discuss a promising solution known as the token handler pattern.

Traditional websites have a single backend that serves HTML and data. User authentication typically occurs on this backend server, which is protected by a network firewall. However, SPAs are connected to multiple microservices via APIs, which creates a more decentralized architecture. While this setup gives SPAs their lightweight advantage, it also introduces significant security risks.

One of the main challenges is that user authentication must often occur in the browser instead of taking place in a protected server behind a network firewall. This makes SPAs vulnerable to a wide range of cyberattack types, such as cross-site scripting (XSS) credential theft. In this attack method, malicious actors can inject code into the browser that is capable of stealing access tokens and user credentials, ultimately granting them unauthorized access to valuable data and systems.

Another challenge arises from the large number of dependencies on third-party data that are typically connected with APIs to the application. High volumes of third-party connections can create a twofold problem.

First, developers have no control over the security that is built into APIs created by other practitioners and organizations. This can lead to vulnerabilities being introduced into the application without the developer's knowledge.

Second, programming in this complex and diverse environment can be tedious because of the large amount of detailed, customized code and input settings that are involved. It can be easy to miss an important step and unknowingly create a security gap. Additionally, hidden security risks can be introduced as the environment grows and adapts to shifting business demands over time.

To further illustrate the challenges, let's compare the setup for securing websites and SPAs.

In securing websites, developers are able to use cookie-based sessions to grant users access to the web application. The frontend website client stores cookies on the browser that are sent to a single backend data server with every user access request. The authorization decisions can be based on the session data kept in storage so user access remains secured behind the network firewall.

This setup isn't possible for SPAs because a single-page application doesn's have a dedicated backend. A content delivery network (CDN) often serves the code to the SPA through static files. These files are returned through API calls to the application. In an SPA configuration, the user's session can't be kept in a cookie because there is no backend data storage. Instead, access tokens can be used to call APIs on behalf of the authenticated user.

SPA Security Vulnerabilities

SPA security challenges hinge on the fact that browser-based authentication is vulnerable to a wide range of cyberattack types. One threat type is cross-site scripting (XSS) credential theft. In this attack method, malicious actors inject code capable of stealing access tokens and user credentials into the browser to gain unauthorized access to valuable data and systems.

While XSS is a common vulnerability, it is not the only one that developers must defend against. To make matters even more difficult, fixing one vulnerability often opens up new ones, which makes securing SPAs a never-ending game of shifting objectives. For instance, using OAuth flows to authenticate user or API access with OAuth tokens instead of session cookies seems like a good way to mitigate XSS attacks.

However, if these tokens are stored in local storage, threat actors can easily gain access to local and session storage to exfiltrate tokens. If tokens can be refreshed, the problem is exacerbated because attackers can gain access even after a user session ends.

Another example of unintended issues that can come with a security fix is building strong security policies into content security policy (CSP) headers. While this can add another layer of security control, some sources may be able to open content security policies and disable them.

The bottom line is the browser is a hostile environment when it comes to defending against unauthorized and malicious access to data and systems. Any security measures require careful testing and constant vigilance to ensure closing one attack vector doesn't open the way for another one.

Using Both Cookies and Tokens

One way of securing SPAs that has recently been developed for protecting user authentication against malicious actors is a token handler pattern that merges website cookie security and access tokens. By implementing a token handler architecture that removes authentication from the browser and leverages a backend-for-frontend (BFF) configuration using same-site cookies and tokens, organizations are able to benefit from the lightweight aspects of SPAs without sacrificing security.

In this setup, an OAuth agent hosted as a backend component sits between the SPA and the authorization server. The OAuth agent handles the OAuth flow for the SPA and instead of the SPA being issued a token, a secure HTTP-only cookie is issued that the SPA can use to gain access to its backend APIs and microservices.

An OAuth proxy hosted in a high-performance API gateway

The above is the detailed content of Single-Page Applications (SPAs) Security Doesn’t Work the Same as Websites. For more information, please follow other related articles on the PHP Chinese website!