How JavaScript runs, and why pentesters read it

Almost every web application you’ll ever test runs JavaScript, and the bugs that matter most now live in the client — in the code running in the browser. This course takes you from “what is a variable” to reading minified bundles, tracing DOM-XSS from source to sink, and understanding why a framework’s escape hatch became an exploit. It’s built for someone who wants to read and weaponise JavaScript, not ship software.

Where JavaScript runs

JavaScript was built to run in the browser, and that’s still where most of it lives — but it also runs on servers (Node.js), in build tools, and in desktop apps. For a security tester, the browser is the interesting place, because that’s where the client-side attack surface is.

Here’s the key insight: when you load a web app, the server sends your browser a pile of JavaScript, and your browser runs it. That code contains the app’s entire client-side logic — its API calls, its routes, sometimes its secrets. You can read all of it. The server can’t hide it, because it had to send it to your browser to run.

// You can run this two ways:
// 1. Open any browser, press F12, go to the Console tab, paste it:
console.log("hello from the browser");

// 2. Save it as hello.js and run it with Node:  node hello.js
console.log("hello from node");

console.log() prints to the console — it’s the JavaScript equivalent of Python’s print. The browser’s DevTools Console (press F12) is your REPL: paste a line, see what it does, immediately.

Why the client side is where the bugs are

Modern apps are JavaScript-heavy single-page applications. The browser does the rendering, the routing, and a lot of the logic. That shift moved a whole class of vulnerabilities into the client:

• DOM-based XSS lives entirely in the browser’s JavaScript — the server never sees it.
• Prototype pollution and postMessage bugs are pure client-side JavaScript.
• The bundle reveals endpoints, secrets, and hidden routes the visible UI never shows.

The mindset: read, don’t just write

Most JavaScript tutorials teach you to build apps. This one teaches you to read them — because that’s what testing requires. You’ll still learn to write JavaScript (you need to, to understand it), but the goal is fluency at reading someone else’s code and spotting what’s dangerous.

Summary

JavaScript runs in the browser (and on servers via Node), and the browser is where the client-side attack surface lives. The server must send the client all its JavaScript to run it, which means you can read the app’s logic, endpoints, and sometimes secrets. The DevTools Console (F12) is your REPL. This course is built around reading code to find what’s dangerous, not just writing apps.

Key takeaways

• JavaScript runs in the browser; that’s where client-side bugs live.
• The client receives all the app’s JavaScript — so you can read it.
• The DevTools Console (F12) runs code in a live page’s context.
• The skill that matters most here is reading code, not writing apps.

Next, the building blocks: variables, data types, and the values every piece of JavaScript is made of.