Securing Single-Page Web Applications
Single-page web apps are massively growing in popularity. Sites such as Airbnb, Pinterest and LinkedIn represent a new approach to designing and building web sites. The single-page app (SPA) is a next-gen web app and offers a faster and cleaner user experience than a traditional web app. It is, as the name suggests, one page, which links to a variety of back-end data sources through application programming interfaces (APIs). Misconfiguration errors across APIs and underlying microservices are some of the main reasons single-page application security offers unique challenges that are not found with their multi-page web app counterparts.
Architectural Differences of SPAs
Multi-page web apps have more than one page, with each page containing its own HTML code. And, while linked navigationally, each page is unique and dynamically generated server-side, unlike SPAs. They might incorporate front-end code to make pages more interactive and dynamic, but their UIs do not primarily use APIs to fetch the application’s data. One classic framework for multi-page apps is a LAMP stack, a Linux-based server running on-premises or in the cloud using Apache web server, MySQL as a relational database system and PHP as the client-side programming language. Each page generally interacts directly with the server and back-end databases for each individual page load.
An SPA, in contrast, is a single-page web app that frequently refreshes itself through multiple API calls. While those APIs may be implemented on a back end similar to a LAMP stack, the back end is increasingly implemented as an ever-changing group of microservices, which may 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 was driven in part by the popularity of the mobile app experience. Their emergence also correlates with the growth of serverless apps and cloud-native services. Additionally, SPAs are primarily built with more modern, client-side development frameworks–such as React, Vue and Angular–than their multi-page brethren.
Different Architecture, Different Vulnerabilities
The SPA’s architecture presents new vulnerabilities for hackers to exploit. With a traditional multi-page web app, AppSec teams need to secure only the individual pages of the app to protect their sensitive customer data. However, with SPAs, the attack surface shifts away from the client layers of the app to the APIs, which serve as the data transport layer that refreshes the SPA. Thus, traditional web AppSec tools like web application firewalls (WAFs) cannot protect SPAs because they do not address the underlying vulnerabilities found in APIs and back-end microservices. A good example of this issue is the 2019 Capital One data breach, in which the hacker reached beyond the client layer; bypassing their WAF and extracting data by exploiting underlying APIs and cloud services hosted on AWS.
Much like how multi-page web apps require indexing of their individual pages, SPAs require proper indexing of all their APIs. For SPAs, their vulnerabilities begin with their APIs. Sophisticated hackers will run multi-level attacks that reach through the client-facing app and look for unauthenticated, unauthorized or unencrypted APIs that are exposed to the internet to hack and extract customer data.
Unauthenticated APIs often come into existence when developers accidentally leave APIs unauthenticated or unauthorized as they update features—a common occurrence with SPAs. Indeed, the very appeal of the SPA is its innate flexibility. Developers can modify APIs endlessly and quickly, a process that is even more apparent when using GraphQL APIs versus the more established REST APIs. Similarly, cloud storage buckets and cloud-native apps can become misconfigured even though they were initially secured when first created and deployed. The rise in misconfiguration errors requires a brand new approach to attack surface management (ASM) for these modern enterprise web applications. To remain secure, companies with SPAs should migrate to a security program that runs continuous, automated discovery of an SPA’s entire attack surface, starting with dynamic analysis of the client-facing app to all of its underlying APIs and through to the back end resources such as storage buckets, serverless cloud functions, containers and database service.
Mitigating the Risks to SPAs
Traditional web application security tools are not suited to analyze and protect SPAs. A standard web AppSec dynamic application security testing (DAST) solution is designed to index the pages of a multi-page app to understand the attack surface at the client layer. It is not set up to deal with multi-faceted attacks that probe for vulnerabilities in dynamically rendered, API-driven applications. Instead, an SPA needs a full stack application security approach. Such a solution should provide attack surface management across all layers of the app stack—client, APIs and cloud services.
Mitigating the risks facing SPAs also requires a continuous full stack AppSec solution. This approach is necessary for two reasons. First, SPAs are constantly changing, with developer changes and updates potentially exposing new vulnerabilities. And second, the attack vectors are evolving simultaneously in parallel. A point-in-time solution is destined to fail and manual penetration testing results are destined to be obsolete. The best security solution for an SPA will run non-stop discovery and vulnerability assessment on all application layers.
At the same time, another SPA security best practice involves using attack automation—an automated “red team,” so to speak—that emulates hackers and ceaselessly identifies potential vulnerabilities. This way, a full stack discovery and remediation solution will never stop checking for vulnerabilities. It works across the client-facing web app and APIs that transport sensitive customer data—as well as across cloud storage, databases and microservices.
Finally, the solution should have the ability to alert developers about vulnerabilities to remediate using their native tools as part of a DevSecOps strategy to minimize disruption to the CI/CD pipeline in the software development life cycle.
