Browser Architecture

A look at how browsers work under the hood

Browser Architecture

A long time ago, the browser was just one huge process. This meant that one small bug in the rendering engine or a plugin could crash the entire browser.

Nowadays, they utilise multi-process architecture, with a host of processes that communicate with another over IPC (Inter-Process Communication). One of the main benefits of this is that one small bug is not as impactful, but it also has a host of security improvements as well.

The Different Processes

We will use Chrome as the example here, as we have previously discussed V8 the most and the resources on it are most abundant.

Image courtesy of the Chrome for Developers page: https://developer.chrome.com/blog/inside-browser-part1

The Browser Process handles all the other processes, delegating work to the others and spinning up new processes when needed. It controls virtually everything about the browser that is not provided by websites or plugins, which means stuff like the address bar and bookmarks as well as network requests and file access.

A Renderer process controls anything regarding the displaying of websites. This includes the HTML, CSS and JS parsing and handling.

Each Plugin process controls a different plugin.

The GPU process takes information from all the different processes so that it knows where to render what.

There are various other processes, such as Extension processes and utility processes.

Security

Now that a browser is multi-process, each process can be restricted to only have permissions for what it needs to do. This means that processes such as the renderer, which deals most with user-supplied untrusted data, can be heavily sandboxed for protection. For example, in Chrome, Renderer processes cannot access files.

Per-Frame Renderer Processes and Site Isolation

Site Isolation, released in Chrome 67 back in 2018, means that Chrome runs a separate Renderer process for each cross-site iframe. This reinforces the Same Origin Policy, the core security model that restricts the data that a site can access from another site without consent. Isolating the processes is the most effective way to enforce this securely.

Browser Attack Vectors

By and large, anything that handles untrusted input is an attack vector. This includes

• HTML/CSS parsers

• JavaScript engines

• DOM bindings (the JavaScript that allows you to control HTML)

• Media codecs (image, audio, video)

• PDF rendering

• Networking stack (especially dangerous as this is in the Browser process!)