JavaScript › Advanced Web Security Research
Browser internals for security research
This is orientation for deeper research: what’s actually under the browser. You won’t write a browser exploit from this lesson, but you’ll understand the architecture that advanced bugs live in — the JavaScript engine, the process model, and the sandbox — so the research world stops being a black box.
You'll learn to
- Name the engine that runs JavaScript
- Understand the multi-process sandbox model
- See where advanced vulnerability classes sit
The JavaScript engine
Your JavaScript doesn’t run directly — an engine compiles and runs it. Chrome and Node use V8; Firefox uses SpiderMonkey; Safari uses JavaScriptCore. These engines use just-in-time (JIT) compilation: they turn hot JavaScript into optimized machine code on the fly.
The process and sandbox model
Modern browsers run as many processes, not one. This is a security boundary.
Browser process privileged — UI, network, file access
|
Renderer processes one (or more) per site — runs the page's JS + DOM
| SANDBOXED: little direct access to the system
Sandbox confines a compromised renderer
A full browser compromise usually needs TWO bugs:
1. a renderer bug (e.g. in the JS engine) to run code in the page's process
2. a sandbox-escape bug to break out into the privileged browser process
The renderer that runs page JavaScript is sandboxed — even if an attacker gets code execution there, the sandbox limits the damage. Escaping to the privileged process takes a second, separate bug. This two-bug requirement is why full browser exploits are rare and valuable.
Checkpoint
Why does a full browser compromise typically require two separate vulnerabilities?
Page JavaScript runs in a sandboxed renderer process with little direct system access. A first bug (such as a JavaScript-engine or JIT flaw) gets code execution inside that renderer, but the sandbox still confines it. A second, separate sandbox-escape bug is needed to break out of the renderer into the privileged browser process that has real system access. The sandbox boundary is what forces the two-bug requirement and makes full exploits rare and valuable.
Try it yourself
Draw the browser’s process model from memory: the privileged browser process, the sandboxed renderer processes per site, and where page JavaScript runs. Mark where a JavaScript-engine bug lands and where a sandbox escape is needed. This mental map orients any advanced reading you do next.
Key takeaways
- An engine (V8, SpiderMonkey, JavaScriptCore) JIT-compiles your JavaScript.
- JIT compiler bugs are a high-value memory-corruption attack surface.
- Browsers are multi-process; the renderer running page JS is sandboxed.
- Full compromise needs two bugs: renderer code-exec plus a sandbox escape.
Quick quiz
Finally, putting the whole course together into a real-world pentesting methodology for modern web apps.