Advanced JavaScript Analysis

Tags: javascript, dom, postmessage, sourcemap, rsc, service-worker, authz, gadgets

Level: advanced

Method

1. Bound the artifact inventory

   Start from authorized pages and observed network traffic. Record script/module/worker URLs, hashes, cache headers, and first-party versus third-party origin. Include dynamic imports, manifest files and chunk manifests; do not enumerate unrelated CDN paths or guess opaque asset names.

   katana -u https://target.example -jc -silent | tee urls.txt; rg '\.(m?js)(\?|$)' urls.txt > js.txt

   Copy

   Tools: katana, getJS, subjs

2. Recover shipped source and framework artifacts

   For each observed bundle, inspect sourceMappingURL and fetch only its adjacent map when published. Preserve the original bundle and map URL. Identify Next/Nuxt/Vite/webpack metadata, RSC/Flight responses, server-action IDs, route manifests, service workers, Worklets, shared workers, and web-worker scripts. A missing map is not a vulnerability.

   cat js.txt | while read u; do sourcemapper -url "$u.map" -output src-dump 2>/dev/null; done

   Copy

   Tools: sourcemapper, jsluice

3. Build a source-to-sink matrix

   Trace attacker-influenced sources (URL/query/hash, postMessage, storage, referrer, BroadcastChannel, WebSocket, API responses) through transforms into sinks: HTML/DOM insertion, URL/navigation, script creation, template compilation, dangerous parsers, fetch/request construction, and worker message handlers. AST search narrows candidates; manual control-flow review establishes reachability.

   semgrep --config=p/javascript src-dump; cat js.txt | jsluice urls

   Copy

   Tools: jsluice, semgrep

4. Audit message and worker boundaries

   For every message listener, record sender window/port/worker, expected schema, origin comparison, and sensitive action. Check targetOrigin on senders, MessagePort transfers, service-worker fetch/message handlers, and cross-origin isolation assumptions. A wildcard alone is a lead; show untrusted data reaches a sensitive behavior.

   Tools: Burp Suite

5. Map client auth and authorization decisions

   Locate token storage, OAuth callback handling, role/feature flags, tenant/object identifiers, API client wrappers, server actions, and route guards. Determine whether a client decision is independently enforced by the server or data endpoint. Test only owned accounts and a single documented authorization boundary; UI-only guards are evidence, not impact by themselves.

   Tools: Burp Suite

6. Chain gadgets only with a real bridge

   Prioritize source→sink flows that can become DOM XSS, token/code disclosure, authenticated cross-origin actions, BOLA/BFLA, open-redirect OAuth code theft, prototype-pollution gadgets, or cache/resource loading impact. Document each bridge and reject chains that depend on an unavailable write primitive, a non-controllable source, or a server check that holds.

   Tools: Burp Suite

7. Preserve skeptic-ready evidence

   Keep asset URL, SHA-256, timestamp, source-map provenance, exact source/sink lines, minimal benign input, and request/response or callback proof. Redact tokens and customer data. State whether the result is a gadget, reachable vulnerability, or validated impact and retest after a fresh load.

Field notes

• Treat client code as a map, not proof: privileged server behavior must be independently confirmed.
• Service-worker scope and update behavior often matter more than the worker registration itself.
• RSC and server-action identifiers are recon; impact requires an authorization or input-handling failure.

References

• https://portswigger.net/web-security/dom-based
• https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
• https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage