JavaScript analysis
When it applies
The app is JS-heavy (SPA). The front-end bundle is a map of the backend: it references API endpoints, parameters, feature flags, roles, and sometimes secrets — much of it not linked in the UI.
Why it works
Client code must know how to call the server, so endpoints/params are embedded in JS. Bundlers also occasionally ship source maps (full original source) and developers leave keys/comments.
Method
- Collect all JS:
katana -jc,subjs, or crawl; grab every.js(incl. lazy-loaded chunks). - Extract endpoints/params:
linkfinder/jsluicepull URLs, paths, and param names from bundles. - Hunt secrets & flags: grep for
apiKey|token|secret|internal|admin|debug, feature flags, and role checks done client-side (server may not enforce them → BOLA/BFLA leads). - Source maps: if
.mapfiles ship, reconstruct original source (source-maptools) → full whitebox-ish view. - Feed results: new endpoints →
api-*; client-only auth checks →api-bola; secrets → validate.
Gotchas
- Client-side "admin" gating usually isn't enforced server-side — test the endpoints directly.
- De-obfuscate/beautify minified bundles before grepping (
js-beautify). - Lazy-loaded chunks hide the juicy routes — enumerate all chunk files, not just
main.js.
Verify success
Endpoints/params/secrets extracted from JS that weren't in the UI — new, testable surface.
References
LinkFinder/jsluice; katana; "JS recon" bug-bounty methodology.