SPA Endpoint & Parameter Map

Overview

A modern JavaScript app does not link its real attack surface. The routes, the /api endpoints, the dynamic segments and the query parameters all live in the client bundle, referenced by the router but never printed in the HTML a crawler reads. So a normal crawl of a Next, Nuxt or React site sees the homepage and a handful of links, and misses most of what the app can actually do. This workflow recovers it: it pulls the app's JavaScript chunks and its __NEXT_DATA__ payload and mines them for every path and parameter the client knows about, runs a crawl alongside, and merges the two into one deduplicated, classified surface. Each endpoint is tagged with the source that found it, so you can see exactly which ones only the JS mining reached. It is token-free and uses no browser, which is what lets it fan across thousands of hosts, and it gives offensive security the endpoint list a DAST or a manual test actually needs.

Pipeline

1. httpx confirms the target is live and fingerprints its stack.
2. Two miners run against it in parallel. The JS miner pulls the app's _next/static chunks and its __NEXT_DATA__ / RSC payload and regex-mines them for page routes, /api endpoints, dynamic route segments and query parameters, and adds the paths from sitemap.xml and robots.txt. katana crawls the rendered app and captures its XHR calls.
3. The two sets and the httpx fingerprint are merged, deduplicated by host and path, and classified into API, dynamic and page routes, with each endpoint carrying the sources that found it.
4. The classified surface is written to a report.

Inputs

• Target list. The hosts to map, as domains or URLs, one per line. Point it at scope you are authorised to test.

Outputs

• Endpoint surface. One row per endpoint, carrying its path, type (API, dynamic or page route), the HTTP methods seen, the query parameters, and the sources that found it.
• Per-source attribution. Whether each endpoint came from the JS mining, the crawl, the sitemap, robots or the fingerprint, so the ones a crawler alone would have missed are visible.
• Report. The classified surface and its counts in one file, ready to feed a DAST run or a manual review.

Sample output

Illustrative, in the record shape the workflow emits. Real runs name live hosts, so the target here is a documentation domain.

Each endpoint carries its type, parameters and the sources that found it. The js-mine-only rows are the ones a crawler alone would have missed:

The run summary counts the surface it recovered:

{"endpoints": 261, "api_routes": 38, "dynamic_routes": 24, "params": 96, "js_mine_only": 71}

FAQ

What does the JS mining find that a crawler misses?

The routes and API calls the client bundle references but the server never renders as links: lazy-loaded pages, admin sections behind a feature flag, the /api calls a button makes on click, and the query parameters those calls take. A crawler only sees what is linked in HTML, so on a SPA it sees a fraction of the app. Reading the JavaScript is what recovers the rest.

How complete is it, honestly?

It recovers close to all of the statically reachable surface and a large share of all public pages. The remainder are links that only exist once the client renders them into the DOM, and no browser-free method can reach those. The workflow is explicit about which endpoints came from which source, so you are never guessing about coverage.

Does it need a browser or credentials?

No. It reads the JavaScript and the app's data payload over plain HTTP, the way any client downloads them, with no headless browser and no login. That is what lets one run fan out across thousands of hosts at once.

Which frameworks does it handle?

It is framework-agnostic and tuned for Next.js, both the App and Pages routers, where it also reads __NEXT_DATA__. Nuxt, React and other bundlers are covered by the same generic chunk and parameter mining, since nothing is hardcoded per site.

Related workflows

• Sitemap URL & Metadata Extractor. Reach for this when a site publishes a real sitemap and you want its content inventory rather than the client-side routes a sitemap never lists.
• Directory and Content Discovery. Reach for this to brute force paths a server exposes but neither the HTML nor the JavaScript references at all.