Single page web applications and how to secure them

App developers like Airbnb, Pinterest, and LinkedIn present a new approach to designing and building modern web apps. By using what is called a single page application (SPA), these apps represent the next generation of modern software design, delivering a faster and cleaner user experience than traditional multi-page websites.

What are single page apps?

SPAs consist of a page displayed by the browser, linking to a variety of primary data sources through application programming interfaces (APIs). SPAs work more like mobile apps than multi-page web apps, and their rise in popularity is in part due to the popularity of the mobile app experience.

Multi-page web applications have more than one page, with each page containing its own HTML code. And, although it is related to navigation, each page is unique and dynamically generated on the server side. Multipage web applications can embed front-end code to make pages more interactive and dynamic, but their user interfaces (UIs) do not primarily use APIs to extract application data.

An example of a multi-page application 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 a client-side programming language. Each page typically 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 made up of a single page web application that refreshes frequently through multiple API calls. While these APIs can be implemented on a backend similar to a LAMP stack, the backend is increasingly implemented as a group of constantly evolving microservices that can be located on one or more cloud platforms. The emergence and popularity of SPAs also correlate with the growth of serverless applications and cloud native services. Additionally, SPAs are mostly built with more modern, client-side development frameworks such as React, Vue, and Angular.

SPA Safety

The SPA architecture presents new vulnerabilities for hackers to exploit, as the attack surface shifts from the client layers of the application to the APIs, which serve as the data transport layer that refreshes the SPA.

With multi-page web applications, security teams only need to secure the individual pages of the application 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 built-in APIs and core microservices. For example, during the Capital One data breach in 2019, the hacker went beyond the customer layer by attacking Capital One’s WAF and mined data by exploiting the underlying API-driven cloud services hosted on AWS.

SPAs require proper indexing of all of their APIs, just as multipage web applications require indexing of their individual pages. For SPAs, vulnerabilities start with APIs. Sophisticated hackers often start with multi-layered attacks that reach the client-side application 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 unsuccessful, hackers often harvest credentials and tokens by leveraging the client layer to access these built-in APIs.

Additionally, the increase in configuration errors, especially in the public cloud, requires a whole new approach to managing attack surfaces (ASM) for these modern web apps.

Developers can change APIs endlessly and quickly, a process that is even more obvious when using GraphQL APIs versus more established REST APIs. Likewise, cloud storage compartments and cloud native applications can be misconfigured even though they were initially secure when created and deployed. Unauthenticated APIs often appear when developers accidentally leave unauthenticated or unauthorized APIs during feature update, which is common with SPAs. Indeed, the very appeal of the SPA is its innate flexibility, and that also causes some of its biggest security flaws.

SPA security

To stay secure, organizations with SPAs must migrate to a security program that performs continuous, automated discovery of the entire attack surface of a SPA, starting with dynamic application-oriented analysis. client to all its underlying APIs and up to the back-end. resources such as storage compartments, serverless cloud functions, containers, and database services.

Traditional web application security tools are not suitable for analyzing and protecting SPAs. A standard Web AppSec Dynamic Application Security Testing (DAST) solution is designed to crawl and index the pages of a multi-page application to understand the attack surface at the client layer, but it is not Designed to deal with multi-faceted attacks that probe for vulnerabilities in applications based on dynamically rendered APIs. Instead, a SPA needs a comprehensive application security approach.

Mitigating the risks faced by SPAs also requires a continuous and comprehensive 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 solution is doomed to fail and the results of manual penetration tests are doomed to become obsolete.

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. With that in place, a full stack discovery and remediation solution will never stop looking for vulnerabilities. It runs on the web application and customer-centric APIs that transport sensitive customer data, as well as cloud storage, databases, and microservices.

A full stack AppSec solution for securing SPAs must have the ability to alert developers to vulnerabilities. But warning is never enough. Auto-remediation to sort and correct immediately before a data breach occurs should be part of a DevSecOps strategy to minimize disruption to the CI / CD pipeline.

The best security solution for an SPA will perform continuous discovery and vulnerability assessment across all application layers. To meet today’s ever-changing web application development and migration requirements to the cloud, organizations must provide attack surface management across all layers of the application stack: client, API and cloud services. Full-stack AppSec solutions are proven to meet these evolving security needs.


Source link

About Jon Moses

Check Also

The new candidate version of X.Org Server appears after a long delay • The registry

More than three years after X.Org Server 1.20, released in May 2018, a release candidate …

Leave a Reply

Your email address will not be published. Required fields are marked *