Single page web applications and how to keep them secure
Application developers such as Airbnb, Pinterest and LinkedIn showcase a new approach to designing and building modern web applications. Using what is known as a single page app (SPA) framework, these apps represent the next generation of modern software design, offering a faster and cleaner user experience than traditional multi-page websites.
What are single page apps?
SPAs are comprised of one browser-rendered page, linking to a variety of back-end data sources through Application Programming Interfaces (APIs). 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.
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. Multi-page web apps might incorporate frontend code to make pages more interactive and dynamic, but their user interfaces (UIs) do not primarily use APIs to pull application data.
An example of a multi-page app is a LAMP stack, a Linux-based server running on-prem 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. This framework now represents a legacy approach to building web applications.
In contrast, an SPA is comprised of a single page web application that frequently refreshes itself through multiple API calls. While those APIs may be implemented on a backend similar to a LAMP stack, the backend is increasingly implemented as an ever-changing group of microservices that may be located on one or more cloud platforms. The emergence and popularity of SPAs also correlate 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.
SPA security
The architecture of SPAs presents new vulnerabilities for hackers to exploit because 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.
With multi-page web apps, security teams need to secure only the individual pages of the app to protect their sensitive customer data. Traditional web security tools such as web application firewalls (WAFs) cannot protect SPAs because they do not address the underlying vulnerabilities found in the embedded APIs and back-end microservices. For example, in the 2019 Capital One data breach, the hacker reached beyond the client layer by attacking Capital One’s WAF and extracted data by exploiting underlying API-driven cloud services hosted on AWS.
SPAs require a proper indexing of all their APIs, similar to how multi-page web apps require an indexing of their individual pages. For SPAs, vulnerabilities begin with the APIs. Sophisticated hackers will often begin with 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. If the first step proves to be fruitless, then hackers often harvest credentials and tokens by exploiting the client layer to access those embedded APIs.
Further, the rise in misconfiguration particularly in the public cloud requires a brand-new approach to attack surface management (ASM) for these modern web applications.
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. 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, and that also causes some of its biggest security flaws.
Securing SPAs
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 services.
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 crawl and index the pages of a multi-page app to understand the attack surface at the client layer, however it is not built 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.
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 all the time in parallel. A point-in-time solution is destined to fail, and manual penetration testing results are destined to be obsolete.
Another SPA security best practice involves using attack automation, an automated “red team” so to speak, that emulates hackers and ceaselessly identifies potential vulnerabilities. With this in place, 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.
A full stack AppSec solution for securing SPAs should have the ability to alert developers about vulnerabilities. But alerting is never enough. Auto-remediation to immediately triage and fix before a data breach occurs must be as part of a DevSecOps strategy to minimize disruption to the CI/CD pipeline.
The best security solution for an SPA will run continuous discovery and vulnerability assessment on all application layers. To meet the requirements of today’s ever-changing web app development and migration to the cloud, organizations need to provide attack surface management across all layers of the app stack—client, APIs and cloud services. Full stack AppSec solutions are proven to deliver on these evolving security needs.