Overview

When reviewing automated scan results, you may notice that some URLs — such as /access-manager, /user-management, or /policy-manager — are not explicitly listed in the sitemap. This can raise concerns about incomplete coverage.

This article explains how the scanner builds the sitemap, why certain URLs may be absent from it, and what that means for your actual scan coverage.

How the Scanner Builds the Sitemap

The scanner records API calls and backend requests made by your application during page loads and navigation. Each captured API call is added to the sitemap to represent the application's attack surface.

The sitemap is therefore a record of actual backend requests — not browser URL changes.

Why Some URLs May Not Appear

Certain modules — such as admin dashboards, settings pages, or management panels — may update the browser's URL path without triggering a new backend API call. This is common in single-page applications (SPAs) where routing happens entirely on the client side.

In these cases:

• The browser shows a new URL (e.g. /access-manager)

• No corresponding backend request is sent to that path

• Since the sitemap is built from actual API calls, the URL does not appear as a separate entry

This does not mean those modules are being skipped. All underlying API calls triggered when the page loads — such as /api/users, /api/roles, or /api/policies — are still captured and scanned.

Example

Consider an admin console module at https://yourdomain.com/access-manager.

When the scanner navigates to this page:

• The browser URL changes to /access-manager

• No new API request is made to /access-manager itself

• The page reuses existing API calls such as /api/users, /api/roles, and /api/policies

• These API calls appear in the sitemap and are included in the scan

The module is being tested — just not listed as a standalone URL entry.

Authentication Flow Limitations (OIDC / SSO with PKCE)

Some applications use advanced authentication mechanisms such as OIDC/SSO with PKCE, often backed by identity providers like Keycloak and fronted by API gateways. These flows can cause issues during automated scanning.

What happens during the scan

The scanner authenticates using an automated headless browser. Certain OIDC + PKCE flows depend on browser state, timing, or interactive redirects that may expire or fail during automated execution.

Common symptoms

• Login works correctly during manual testing but fails during the scan

• Authentication callbacks return errors such as authentication_expired or temporarily_unavailable

• The login endpoint does not appear in the sitemap

• Only public or unauthenticated pages are crawled

What this means for coverage

If authentication does not complete successfully, the scanner cannot reach protected areas of the application. Authenticated URLs and APIs will not appear in the sitemap as a result.

Recommended actions

• Re-record the login flow if recent changes were made to the login page (for example, a new landing page was added before the login screen)

• If the issue persists, switch to session cookie or token-based authentication instead of browser-based login recording — this provides more reliable access to authenticated areas

• If automated login is not feasible, contact Astra support to import a HAR file captured from a successful manual login session. This allows the scanner to reuse authenticated requests and ensure full coverage of protected areas

What To Do If You Suspect a Module Is Being Skipped

1. Review the API calls listed in the sitemap and check whether the underlying requests for that module are present.

2. If you still believe a module is not being covered, share the example URL and the expected API request with Astra support — the team will verify the configuration for you.

Need Help?

Raise a support ticket from your Astra dashboard if you have questions about your scan results or want to confirm coverage for a specific module.