How to Scan a Single Page Application (SPA)

Last updated: July 27, 2025

Single Page Applications (SPAs) are modern web applications that dynamically update the content on a single web page, typically by consuming APIs in the background. To ensure complete coverage during a security scan, our platform uses browser-based crawling combined with intelligent detection of API usage.

Steps to Scan an SPA

1. Configure the Web Target

Add your SPA as a Web Target in the platform. Set the Scope URI to point to the root of your web application (e.g., https://app.example.com).

2. Create a Login Recording

If the application requires login, create a Login Recording. This simulates the user login flow and allows the scanner to authenticate and access protected parts of the app.

  • The scanner will use this recording during the crawl.

  • Once authenticated, it will explore the UI and capture all pages and APIs that are triggered as part of the interaction.

Note: The authentication method used in the login recording must match the one required by your app’s API.

3. Crawling and Scanning

The scanner uses a real browser to:

  • Follow links, interact with UI elements, and trigger background API calls

  • Capture all API endpoints called from the front-end

  • Automatically perform security scans on both the UI and the captured APIs

What About APIs Not Used in the UI?

If there are APIs that are not triggered through the SPA UI, they will not be captured automatically during crawling. You can add them manually using any of the following options:

  • Upload an OpenAPI (Swagger) file that defines the endpoints

  • Import API endpoints via:

    • HAR file (recorded using browser or tools like Chrome DevTools)

    • Postman Collection

    • Astra CLI

Ensure that the manually added endpoints use the same authentication method as the APIs consumed by the web application. This allows them to be scanned using the same login recording or session.

Scanning SPAs That Use Microservices

Many modern SPAs consume APIs served by multiple backend microservices. Our platform is designed to detect and scan these APIs automatically during a crawl, as long as they are within the configured scope and extra host settings.

Unified Scanning and Reporting

If all the microservices are under the same domain or are included in the extra hosts configuration, the scanner will:

  • Discover and crawl the SPA UI

  • Detect and scan all API endpoints triggered by the frontend (even if they belong to different services)

  • Report all findings as part of a single scan report tied to the web target

Example:
Your SPA at https://app.example.com consumes APIs from:

  • https://api.example.com/users

  • https://orders.example.internal

  • https://billing.example.com

If these domains are in-scope (either as part of the main URI or added as extra hosts), the scanner will automatically include their endpoints and show all results in one consolidated report.

Reporting Per Microservice

If you need separate reports per microservice, we recommend configuring API targets instead of relying on a single web target. This allows more focused control over scanning and reporting.

However, API targets do not perform crawling, since there is no UI to explore. Instead, you can populate the inventory using:

  • API observability or instrumentation integrations

  • Astra CLI

  • HAR files (from browser sessions or tools like Postman)

  • OpenAPI (Swagger) specs

In this setup, each API target can have its own:

  • Authentication configuration (such as Bearer token or API key)

  • Scan schedule

  • Report

Example:
You configure three API targets:

  • Users Service: endpoints from https://api.example.com/users

  • Orders Service: endpoints from https://orders.example.internal

  • Billing Service: endpoints from https://billing.example.com

Each service is scanned and reported independently. You’ll receive individual vulnerability reports for each microservice.

Option: Segmenting Web Targets

If you still want to configure the system as a Web Target, but prefer segmented crawling and reporting, you can create multiple web targets that point to the same SPA URL and use URL exclusion rules to narrow the scope of each scan.

Example:

  • Target A (Users): URI = https://app.example.com, Exclude: /orders/*, /billing/*

  • Target B (Orders): URI = https://app.example.com, Exclude: /users/*, /billing/*

  • Target C (Billing): URI = https://app.example.com, Exclude: /users/*, /orders/*

During crawling, each scan will capture only the relevant APIs based on the exclusion filters. This provides more focused results while still relying on the SPA’s UI interactions.