How-To: Scanning a Single Page Application (SPA)

Last updated: May 29, 2026

Introduction

Single Page Applications (SPAs) are modern web applications that dynamically update content on a single page, typically by consuming APIs in the background. Unlike traditional scanners, Astra uses real browser automation (Chromium and Firefox) to fully render and interact with SPAs, ensuring that JavaScript-heavy elements and client-side routing (such as React, Vue, or Angular) are thoroughly mapped

Prerequisites

  • You must have an active Astra Dashboard account.

  • You should have the root URL of your web application ready.

  • If your application requires authentication, ensure you have valid user credentials and are prepared to record a login sequence.

Instructions

1. Configure the Web Target

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

2. Create a Login Recording

If your application has restricted areas, you must create a Login Recording. This simulations the user login flow, allowing the scanner to authenticate and explore protected UI elements and APIs triggered during interaction.

  • Note: The authentication method in your recording must match what your app's API requires.

3. Initiate Crawling and Scanning

Once the target is set up, the scanner will use a real browser to perform the following automatically:

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

  • Capture all API endpoints called from the frontend, including XHR, fetch, and WebSocket requests.

  • Execute security tests on both the frontend UI and all captured background APIs.

4. Add Missing APIs Manually

If your SPA has background APIs that are not triggered through the UI, they will not be captured automatically during the crawl. To ensure full coverage, you can manually import these endpoints using:

  • OpenAPI (Swagger) files.

  • Postman Collections or HAR files.

  • Astra CLI.

5. Segment Large Applications (Optional)

If your SPA uses multiple microservices, the scanner will report all findings in a single report if they are within the same domain. For more focused control, you can configure separate API targets for each microservice, allowing for independent scan schedules and reports.

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.

Step 6 (Optional): Scan SPAs with Multiple Microservices as a Single Target

If your SPA consumes APIs from multiple backend microservices, the scanner automatically detects and scans all API endpoints triggered by the frontend during the crawl, as long as those domains are within your configured scope or added as extra hosts. All findings are reported in a single consolidated report tied to the web target. For example, if your SPA at https://app.example.com calls https://api.example.com/users, https://orders.example.internal, and https://billing.example.com, all three will be scanned and reported together provided they are in scope or added as extra hosts.

Step 7 (Optional): Configure Separate API Targets for Per-Microservice Reporting

If you need separate reports per microservice, configure individual API targets instead. API targets do not perform crawling since there is no UI to explore. You will need to populate the inventory manually using:

  • API observability or instrumentation integrations

  • Astra CLI

  • HAR files from browser sessions or tools like Postman

  • OpenAPI (Swagger) specs

Each API target gets its own authentication configuration (such as Bearer token or API key), scan schedule, and report. For example, you could configure three separate targets — Users Service at https://api.example.com/users, Orders Service at https://orders.example.internal, and Billing Service at https://billing.example.com — and receive independent vulnerability reports for each

Expected Outcome

After the scan is initiated, the crawler will generate a Sitemap representing every reachable page and API endpoint. You will receive a comprehensive report that details vulnerabilities found within both the SPA's frontend and its supporting backend services.

Troubleshooting & Best Practices

  • URL Fragments (#): SPAs often use "#" fragments for routing. Astra inspects all network activity within these fragments, but they are not listed as separate entries in the sitemap to avoid redundancy.

  • Dynamic Parameters: If your URLs use unique IDs (e.g., /user?id=1), Astra groups them into a single route pattern to prevent redundant testing.

  • Data-Dependent Pages: Some pages (like "Track Delivery") only appear under specific conditions. Ensure your login recording mimics the necessary user interactions to expose these views.

  • WAF/Firewall Blocking: If the scanner cannot connect, ensure you have allowlisted Astra's static IP addresses in your firewall or Cloudflare settings.