Single page applications are hot. More and more frequently, companies are building their web applications as a single page application. With a single page application, the front end dynamically changes as a user moves through the application, leveraging an API layer for data and logic. All of this results in a faster and improved user experience.
As companies deploy single page applications, however, they are faced with a new challenge - how to ensure that they are secure. Security and engineering teams know that single page applications bear most of the same security risks found in a traditional web application, but traditional security testing approaches do not work.
Read on below for an overview of the trouble with security testing single page apps and how to test single page apps for security vulnerabilities. 🤫 ...if you want a little hint, it’s all about testing the backing APIs.
Why Security Tests for Single Page Apps is Different
A key element of single page applications is a changing DOM (document object model). Javascript executes as a user interacts with the application, resulting in different DOMs on the same URL, without the page reloading. Single page applications are more performant and provide a better user experience, which has led to their growth in popularity. This changing page structure, however, presents challenges for traditional security testing.
HTML Spiders Don’t Work for Single Page Apps 🚫🕷
Dynamic application security testing tools are built on a foundation of application spidering. A scanner spiders application via the HTML, building a tree of all possible paths and routes. Then, the scanner runs a series of automated tests against those paths and routes, returning a list of potential security vulnerabilities.
When it comes to testing single page applications, these HTML spiders simply do not work. The spider looks at the HTML on a certain path and misses the page elements that could potentially render based on a user’s interaction. As a result, security tests with traditional tools and approaches leave a significant portion of the application untested, resulting in vulnerabilities potentially existing in production.
Ajax Spiders as an Option for Single Page Applications 🤷🕷
As a result of the HTML spidering problem described above, many security tools introduced ajax spiders. Ajax spiders crawl the application, executing the functions that are identified, and building a more robust list of paths and routes. This approach helps with the changing DOM problem, as the scanner steps through the possible functions instead of relying on the HTML.
Problem solved, right?
Unfortunately, while ajax spiders are a step in the right direction, they still fall short when it comes to security testing for single page apps. There are two primary concerns with ajax spiders - speed and thoroughness.
An ajax spider of an application is typically quite slow. For some development teams, this is not a concern, but for teams that deploy frequently and run automated tests in CI/CD, their security testing must be highly performant. An ajax spider is simply too slow for the development and deployment pace of many modern software teams.
Additionally, while ajax spiders create a far more complete list of paths and routes than an HTML spider, they still often present an incomplete view.
How to Test Single Page Applications for Vulnerabilities
The key to security testing for single page applications is testing the underlying APIs. While the front end changes based on interactions in the application, the backing APIs are consistent. With security tests implemented against the backing APIs, a company is able to test for the majority of vulnerabilities that can exist in a single page application. And most other vulnerabilities can be found by an HTML spider, as these front end vulnerabilities typically exist site wide.
So how does it work?
Step 1: Pick a Security Tool for Single Page Apps 🛠
First, select a security testing tool. Be sure to select a tool that is fully functioned for API security testing (check out our API Security Testing Tooling Guide to help identify what to look for). Here at StackHawk, we offer best-in-class API security testing capabilities. There are other tools on the market as well, but you can easily get started with our free account for your testing.
Step 2: Configure for Testing the API ⚙️
After selecting a tool, the tool must be configured to test the APIs. This is done by providing the scanner a list of the API routes. In StackHawk, for example, there are a few ways to do this:
OpenAPI Specification for REST APIs
GraphQL Introspection Endpoint for GraphQL APIs
WSDL File for SOAP APIs
Having a documented API is key here. If your team is not already using OpenAPI specification or using GraphQL (which is self documenting via the introspection endpoint), you should embrace this best practice and begin documenting your API. There are some useful tools to help you get started, including SmartBear’s Swagger Editor, the OpenAPI Generator, or language specific methods as described in the StackHawk docs.
Step 3: Scan the API for Vulnerabilities 🔎
With all of that in place, you can kick off a scan of your API in a pre-production environment and then review the findings. Running a scan with StackHawk is as simple as a single Docker command in your CLI. Other tools generally run as a hosted scanner, operating in the cloud. While this sounds like a great option initially, note that these scanners are typically built for scanning production applications (which is dangerous if you have a vulnerability!) and not ideal for automation.
Step 4: Scan the Front End for Vulnerabilities 🔎
While an HTML spider leaves much of the application untested (hence, the notes above on why you should test the API), you should still test the front end HTML for things such as DOM XSS and cookie related vulnerabilities. The good news is that these are typically a site wide error (and also a simple site wide fix).
Depending on your configuration of the scanner, a single scan may encompass both steps 3 and 4. However, for optimal performance, teams will often scan the front end and backing APIs separately.
Step 5: Automate Your Security Testing 🤖
After an initial security test of your single page application, it is time to automate the testing in CI/CD. With automated application security, your team will be notified early in the development lifecycle when a new vulnerability is introduced instead of being surprised weeks (or even months!) later from a security team audit or external penetration test.
A best practice is to establish a baseline after the first scan, allowing all existing vulnerabilities to be prioritized and fixed among other engineering work. With this in place, an engineering team can safely instrument automation in blocking mode, breaking the build if a new vulnerability is introduced. StackHawk has triage actions built into the platform, allowing teams to automatically send findings to Jira or accept the risk of certain findings, making it simple to use the platform to catch all new security bugs.
Deliver Secure Single Page Apps Today
Oftentimes, getting started with security testing is the hardest part. However, it is often more daunting than it seems. Most StackHawk users are able to successfully run their first security test in less than 15 minutes, and our support team is always ready to help if you encounter any issues. Don’t build up more security technical debt - get started testing today!
