Single-page web apps are becoming increasingly popular. Sites like Airbnb, Pinterest and LinkedIn represent a new approach to website design and creation. The Single Page App (SPA) is a next generation web app and offers a faster and cleaner user experience than a traditional web app. As the name suggests, it is a page that references a variety of back-end data sources through application programming interfaces (APIs). Misconfiguration errors in APIs and underlying microservices are some of the main reasons that single-page application security presents unique challenges not found in their multi-page web app counterparts.
Architectural differences between SPAs
Multipage web apps have more than one page, with each page containing its own HTML code. And although it is linked through the navigation, each page is different from SPAs and is generated dynamically on the server side. They may incorporate front-end code to make pages more interactive and dynamic, but their user interfaces don’t primarily use APIs to get the application’s data. A classic framework for multi-sided apps is a LAMP stack, a Linux-based server that runs locally or in the cloud with Apache web server, MySQL as the 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.
A SPA, on the other hand, is a one-page web app that often updates itself through multiple API calls. While these APIs can be implemented on a back end similar to a LAMP stack, the back end is increasingly being implemented as an ever-changing group of microservices that can reside on one or more cloud platforms. In this way, SPAs work more like mobile apps than multi-page web apps, and their popularity has been 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. In addition, SPAs are primarily built using more modern, client-side development frameworks such as React, Vue, and Angular than their multi-sided brethren.
Different architecture, different weak points
The architecture of the SPA offers new vulnerabilities that hackers can exploit. With a traditional multi-page web app, AppSec teams only need to secure the individual pages of the app to protect their sensitive customer data. With SPAs, however, the attack surface shifts away from the app’s client layers and towards the APIs, which serve as the data transport layer that updates the SPA. As a result, traditional Web AppSec tools like Web Application Firewalls (WAFs) cannot protect SPAs because they fail to address underlying vulnerabilities in APIs and back-end microservices. A good example of this problem is the 2019 Capital One data breach, where the hacker reached beyond the client level; Bypass your WAF and extract data using the underlying APIs and cloud services hosted on AWS.
Similar to how multi-page web apps require their individual pages to be indexed, SPAs require all of their APIs to be properly indexed. With SPAs, their weaknesses start with their APIs. Sophisticated hackers carry out tiered attacks that extend through the client-side app looking for unauthenticated, unauthorized, or unencrypted APIs exposed to the internet to hack and extract customer data.
Unauthenticated APIs often arise when developers inadvertently leave APIs unauthenticated or unauthorized while updating features – a common occurrence with SPAs. In fact, the attraction of the SPA lies in its innate flexibility. Developers can change APIs endlessly and quickly, a process that becomes even more evident when using GraphQL APIs compared to the more established REST APIs. Likewise, cloud storage buckets and cloud-native apps can be configured incorrectly, even though they were originally secured when they were initially created and deployed. The rise in misconfiguration errors calls for an entirely new approach to attack surface management (ASM) for these modern enterprise web applications. To stay secure, companies with SPAs should migrate to a security program that performs continuous, automated detection of the entire attack surface of a SPA, starting with the dynamic analysis of the client-side app through all the underlying APIs to the back-end resources such as e.g. storage buckets, serverless cloud functions, containers and database services.
Mitigation of Risks for SPAs
Conventional security tools for web applications are not suitable for analyzing and protecting SPAs. A standard Web AppSec dynamic application security testing (DAST) solution is designed to index the pages of a multipage app to understand the attack surface at the client level. It is not designed to deal with multifaceted attacks that look for vulnerabilities in dynamically rendered, API-driven applications. Instead, a SPA requires a complete application security approach. Such a solution should enable attack surface management across all levels of the app stack – client, APIs and cloud services.
To mitigate the risks of SPAs, a full-stack, continuous AppSec solution is also required. This approach is necessary for two reasons. First, SPAs are constantly changing, with developer changes and updates potentially exposing new vulnerabilities. Second, the attack vectors develop in parallel at the same time. A point-in-time solution is doomed and manual penetration test results are out of date. The best security solution for a SPA performs uninterrupted detection and vulnerability assessment at all application levels.
At the same time, another best practice for SPA security is to use attack automation – an automated “red team” so to speak – that emulates hackers and ceaselessly identifies potential vulnerabilities. That way, a full-stack detection and remediation solution never stops looking for vulnerabilities. It works via the client-side web app and APIs that transport sensitive customer data, as well as via cloud storage, databases and microservices.
Ultimately, the solution should be able to inform developers about vulnerabilities as part of a DevSecOps strategy in order to fix them with their native tools in order to minimize disruptions to the CI / CD pipeline in the software development lifecycle.
Comments are closed.