Single-page web applications are becoming increasingly popular. Sites like Airbnb, Pinterest, and LinkedIn represent a new approach to website design and creation. The Single Page Application (SPA) is a next-generation web application and provides a faster and cleaner user experience than a traditional web application. It is, as the name suggests, a page, which links to a variety of backend data sources through application programming interfaces (APIs). Misconfiguration errors in the APIs and underlying microservices are some of the main reasons why single-page application security offers unique challenges not found with their counterparts in multi-page web applications.
Architectural differences of SPAs
Multi-page web applications have multiple pages, with each page containing its own HTML code. And, although linked at the navigation level, each page is unique and dynamically generated on the server side, unlike SPAs. They may incorporate front-end code to make pages more interactive and dynamic, but their user interfaces don’t primarily use APIs to retrieve application data. A classic framework for multi-page applications is a LAMP battery, a Linux-based server running on-premises or in the cloud using the Apache web server, MySQL as the relational database system, and PHP as the client-side programming language. Each page typically interacts directly with the server and backend databases for each individual page load.
A SPA, on the other hand, is a single-page web application that refreshes frequently through multiple API calls. Although these APIs can be implemented on a backend similar to a LAMP stack, the backend is increasingly implemented as an ever-evolving group of microservices, which can be located on one or more cloud platforms. In this way, SPAs function more like mobile apps than multi-page web apps, and their rise to prominence has been driven in part by the popularity of the mobile app experience. Their emergence is also correlated with the growth of serverless applications and cloud-native services. Additionally, SPAs are mostly built with more modern client-side development frameworks like React, Vue, and Angular than their multi-page brethren.
Different architecture, different vulnerabilities
The SPA architecture introduces new vulnerabilities for hackers to exploit. With a traditional multi-page web application, AppSec teams only need to secure individual pages of the application to protect their sensitive customer data. However, with SPAs, the attack surface moves from the client layers of the application to the APIs, which serve as the data transport layer that actualizes the SPA. Thus, traditional AppSec web tools such as web application firewalls (WAFs) cannot protect SPAs because they do not patch underlying vulnerabilities found in back-end APIs and microservices. A good example of this problem is the 2019 Capital One data breach, in which the hacker reached beyond the customer layer; bypassing their WAF and extracting data by exploiting the underlying APIs and cloud services hosted on AWS.
Much like how multi-page web applications require their individual pages to be indexed, SPAs require proper indexing of all of their APIs. For SPAs, their vulnerabilities start with their APIs. Sophisticated hackers will launch multi-layered attacks that will reach the customer-facing application and look for unauthenticated, unauthorized or unencrypted APIs that are exposed to the internet to hack and extract customer data.
Unauthenticated APIs often appear when developers accidentally leave unauthenticated or unauthorized APIs when updating features, which is common with SPAs. Indeed, the very attraction of the SPA is its innate flexibility. Developers can modify APIs endlessly and quickly, a process even more evident when using GraphQL API compared to more established REST APIs. Similarly, cloud storage buckets and cloud-native applications can be misconfigured even though they were initially secured when created and deployed. The increase in misconfigurations requires a whole new approach to attack surface management (ASM) for these modern enterprise web applications. To stay secure, organizations with SPAs should migrate to a security program that performs continuous, automated discovery of the entire attack surface of a SPA, starting with dynamic application scanning. customer-oriented to all its underlying APIs and down to back-end resources such as storage buckets, serverless cloud functions, containers, and database service.
SPA Risk Mitigation
Traditional web application security tools are not suitable for analyzing and protecting SPAs. A standard AppSec Dynamic Application Security Testing (DAST) web-based solution is designed to index the pages of a multi-page application to understand the attack surface at the client layer. It is not configured to deal with multifaceted attacks that seek vulnerabilities in API-driven and dynamically rendered applications. Instead, an SPA needs a comprehensive application security approach. Such a solution should provide attack surface management across all layers of the application stack: client, API, and cloud services.
Mitigating the risks faced by SPAs also requires a comprehensive and ongoing AppSec solution. This approach is necessary for two reasons. First, SPAs are constantly changing, with changes and updates from developers potentially exposing new vulnerabilities. And second, the attack vectors simultaneously evolve in parallel. A point solution is doomed to failure, and manual penetration testing results are doomed to be obsolete. The best security solution for a SPA will perform continuous vulnerability detection and assessment across all application layers.
Meanwhile, another SPA security best practice is to use attack automation, an automated “red team,” so to speak, that emulates hackers and continually identifies potential vulnerabilities. This way, a full stack detection and remediation solution will never stop looking for vulnerabilities. It runs on the customer-facing web application and APIs that transport sensitive customer data, as well as cloud storage, databases, and microservices.
Finally, the solution must have the ability to alert developers to vulnerabilities that need to be patched using their native tools as part of a DevSecOps strategy to minimize disruptions to the CI/CD pipeline in the development lifecycle software.