JavaScript › Real-World Pentesting Methodology
A methodology for testing modern web apps
This capstone turns everything into a repeatable workflow for modern, JavaScript-heavy applications. Single-page apps, React/Angular frontends, and API-driven designs need a different approach from classic server-rendered sites — and you now have every piece. The thread is the course’s theme: read the client to understand the server, then test the server, because the server is what enforces security.
You'll learn to
- Follow a repeatable SPA testing workflow
- Map an app from its own JavaScript
- Focus effort where real bugs live
The workflow
-
Map from the bundle. Fetch and beautify the JavaScript, check for source maps, and extract every endpoint, route, and secret. The frontend documents the backend — start there.
-
Enumerate the API. Those endpoints are the real attack surface in an SPA. Catalogue methods, parameters, and which require auth.
-
Test authorization first. Run the auth-matrix and IDOR checks across the API. Broken access control is the most common and impactful SPA bug, and it lives entirely on the server.
-
Hunt client-side bugs. Trace DOM-XSS source-to-sink, check the framework escape hatches, and look for prototype-pollution sinks in the merge/clone helpers.
-
Check the client/server trust boundary. Anything the client enforces (hidden buttons, disabled fields, role checks in JavaScript) is not security — re-test every such action directly against the API.
Where the bugs concentrate
SPA / API-driven app — highest-yield areas:
- Broken access control on API endpoints (IDOR, missing role checks)
- Endpoints reachable but not linked in the UI (found in the bundle)
- Mass assignment (sending extra JSON fields the API trusts)
- DOM XSS via client-side routing and templating
- JWT and client-side auth handling flaws
Checkpoint
Why is 'client-side controls are not security controls' the defining principle for testing modern web apps?
Because the attacker fully controls the client — they can read all the JavaScript, modify it, and call the API directly, bypassing anything the frontend enforces. A hidden button, disabled field, or role check in JavaScript only affects the UI; it provides no real protection. Only the server can enforce security, since it's the one place the attacker doesn't control. So every client-side restriction must be re-tested directly against the API, and any action the server allows that it shouldn't is the real finding.
Try it yourself
Sketch your testing workflow for a React SPA from memory: map from the bundle, enumerate the API, test authorization, hunt client-side bugs, check the trust boundary. For one step — testing authorization — describe the concrete checks you’d run against the discovered endpoints.
Key takeaways
- Map the app from its bundle; the frontend documents the backend.
- The API is the real attack surface — enumerate and test it directly.
- Test authorization first; broken access control is the top SPA bug.
- Client-side controls are not security — re-test everything against the server.
Quick quiz
That completes the JavaScript course — from first variable to a full methodology for testing modern web applications.