How CORB Protects Sensitive Cross-Origin Data in Firefox

This article provides a comprehensive explanation of Cross-Origin Read Blocking (CORB) and details how it safeguards user information within the Mozilla Firefox web browser. It covers the fundamental definition of CORB, the side-channel security vulnerabilities it mitigates, how its content-filtering algorithm operates, and how Firefox specifically integrates this feature alongside site isolation to block unauthorized access to sensitive cross-origin data.

What is Cross-Origin Read Blocking (CORB)?

Cross-Origin Read Blocking (CORB) is a web platform security algorithm designed to prevent malicious websites from accessing sensitive data from other origins (domains).

Normally, the browser's Same-Origin Policy (SOP) restricts a website from reading data fetched from a different domain unless explicitly allowed by Cross-Origin Resource Sharing (CORS) headers. However, exceptions exist for certain HTML tags like <img> and <script>, which are permitted to request resources across origins. Historically, the browser would download the requested cross-origin resource into the web page's memory space before the Same-Origin Policy blocked the page from actually reading it. CORB upgrades this security by stopping dubious cross-origin loads from ever entering the web page's memory space in the first place.

The Threat: Why CORB is Necessary

The primary reason CORB was developed is to mitigate speculative execution side-channel attacks, most notably Spectre.

When a web page loads, it operates inside a specific operating system process called a renderer or content process. If a malicious website uses an <img> tag to request a sensitive file from another website (such as a user's private banking data formatted in JSON), the browser fetches that file. Without CORB, the file is placed into the memory of the malicious website's content process, even though the browser ultimately refuses to display it as an image.

Because the sensitive data is now sitting in the same memory space as the attacker's code, the attacker can use a Spectre attack to read the memory directly, completely bypassing the Same-Origin Policy. CORB prevents the sensitive data from ever entering that memory space.

How CORB Protects Sensitive Data

CORB targets three specific types of data that frequently contain sensitive user information and have no legitimate reason to be loaded into tags like <img> or <script> without CORS permissions:

  • HTML (text/html)
  • XML (application/xml and text/xml)
  • JSON (application/json)

When a cross-origin request is made without CORS, CORB intercepts the incoming response and performs the following steps:

  1. MIME Type Check: It checks the Content-Type header of the response to see if it claims to be HTML, XML, or JSON.
  2. Content Sniffing: Because web servers sometimes mislabel files (for example, labeling a JavaScript file as text/html), CORB inspects the first few bytes of the response body. It confirms whether the file actually matches the formatting of HTML, XML, or JSON. (If the server sends a X-Content-Type-Options: nosniff header, CORB skips sniffing and trusts the MIME type).
  3. Blocking: If the resource is confirmed to be one of the protected data types, CORB intercepts the data, strips the response body and headers, and hands the webpage an empty response instead.

Because this happens before the data reaches the web page, a side-channel attack has nothing to steal.

How CORB Works in the Firefox Web Browser

Mozilla Firefox implements CORB as a critical layer of its multi-process security architecture, working directly alongside Project Fission (Firefox's implementation of Site Isolation).

In Firefox, the browser is split into different processes: a privileged Parent Process that handles networking and system tasks, and multiple unprivileged Content Processes that render individual websites.

Here is how Firefox executes CORB to protect your data:

  1. Network Interception: When a website in a Firefox Content Process requests a cross-origin file, the request is handled by the Parent Process.
  2. Parent Process Filtering: As the external server sends the data back to Firefox, the CORB algorithm runs inside the secure Parent Process. The Content Process has zero access to the data at this stage.
  3. Sanitization: If the Parent Process detects that the cross-origin request is attempting to load HTML, XML, or JSON into an incompatible context (like an image or script tag), it drops the payload immediately.
  4. Safe Delivery: The Parent Process sends an empty byte stream to the Content Process. The sensitive data is discarded in the Parent Process and never crosses the boundary into the unprivileged memory space where the website's code is running.

By combining CORB with Project Fission—which ensures that different websites are always placed into entirely separate Content Processes—Firefox provides a defense-in-depth approach. Even if an attacker attempts to exploit complex CPU vulnerabilities, CORB ensures that sensitive cross-origin text data is filtered out at the network layer, keeping user data secure.