# Brave's Security Model Regarding IPC and Chromium Security Rules

> Discover Brave's security model leveraging Chromium's sandbox to validate IPC messages, ensuring least privilege and secure cross-process communication.

- Repository: [Brave Software/brave-browser](https://github.com/brave/brave-browser)
- Tags: deep-dive
- Published: 2026-02-19

---

**Brave inherits Chromium's multi-process sandbox architecture and Mojo IPC system, enforcing strict allow-lists, capability-based permissions, and automated security checks to ensure only validated, least-privilege messages cross process boundaries.**

The `brave/brave-browser` repository builds upon Chromium's hardened browser foundation, adopting its robust inter-process communication (IPC) framework while implementing additional review gates. Understanding Brave's security model regarding IPC and Chromium security rules is essential for developers contributing to the browser's core architecture or auditing its attack surface.

## Core Principles of Brave's IPC Security Model

Brave's architecture inherits Chromium's multi-process design, where the UI, network, GPU, and each renderer run in separate sandboxed processes. All data crossing process boundaries travels through Chromium's **Mojo IPC** system, enforced through the following principles:

| Principle | Implementation | Enforcement Location |
|-----------|----------------|---------------------|
| **Process isolation** | Each tab, extension, and web content runs in its own sandboxed renderer with limited system calls and file-system access. | `content/renderer/*`, `chrome/browser/sandbox/*` |
| **Strict allow-list of IPC messages** | Only reviewed and approved messages are compiled into the browser; new messages must pass the IPC review checklist. | [`chrome/common/ipc_message_start.h`](https://github.com/brave/brave-browser/blob/main/chrome/common/ipc_message_start.h), [`chrome/common/ipc_message_utils.h`](https://github.com/brave/brave-browser/blob/main/chrome/common/ipc_message_utils.h) |
| **Message validation** | Every incoming Mojo message is validated against generated bindings; malformed payloads cause immediate sender termination. | `mojo/public/cpp/bindings/lib/*.cc` |
| **Capability-based permissions** | IPC interfaces expose only minimal required methods (e.g., `Renderer` cannot invoke `Browser::DeleteAllCookies`). | `chrome/browser/.../mojom/*.mojom` |
| **Policy enforcement** | CSP, Safe-Browsing, and content settings are checked before renderers fetch resources. | `chrome/browser/content_settings/*` |
| **Static analysis & review** | Build-time `ipc_security_check` tool automatically validates new IPC messages against security rules. | `tools/ipc/`, build scripts |

## How Brave Implements Chromium's Security Rules

Brave does not re-implement a separate IPC security layer. Instead, it **adopts** Chromium's proven mechanisms and adds **Brave-specific review gates** to ensure every change to the IPC surface undergoes rigorous scrutiny.

### Process Isolation and Sandboxing

The browser leverages Chromium's multi-process architecture where the UI, network, GPU, and each renderer run in separate sandboxed processes. In `content/renderer/*` and `chrome/browser/sandbox/*`, the sandbox limits system calls, file-system access, and device usage for each process type.

### Strict Allow-Lists and Message Validation

All IPC messages must be explicitly registered in the allow-list defined in [`chrome/common/ipc_message_start.h`](https://github.com/brave/brave-browser/blob/main/chrome/common/ipc_message_start.h) and [`chrome/common/ipc_message_utils.h`](https://github.com/brave/brave-browser/blob/main/chrome/common/ipc_message_utils.h). New messages must include the `IPC_REVIEW` comment flag and pass the build-time `ipc_security_check` tool located in `tools/ipc/`. This static analysis enforces that every message adheres to the **IPC review checklist** before compilation.

### Capability-Based Permissions

Brave implements **capability-based permissions** through Mojo interface definitions (`.mojom` files) that explicitly limit which processes can invoke specific methods. Each interface exposes only the minimal set of methods required for a specific component. For example, a sandboxed `Renderer` process cannot invoke `Browser::DeleteAllCookies` because the interface binding in `chrome/browser/.../mojom/*.mojom` restricts such high-privilege operations to trusted processes only.

## Code Examples

### Defining a Mojo IPC Interface with Least-Privilege Methods

The following `.mojom` file demonstrates how Brave defines an interface that exposes only the minimal functionality required, preventing direct file-system access:

```cpp
// brave/browser/ads/ads.mojom
module brave.ads;

interface AdsProxy {
  // Only the UI process can request an ad-click.
  // No method exposes direct file-system access.
  ClickAd(string ad_id) => (bool success);
};

```

The generated bindings automatically enforce message validation; any malformed `ad_id` payload will cause the sender process to be terminated immediately.

### Adding a New IPC Message with Security Review Comments

When adding new IPC messages, developers must include review checklist comments that the build system validates:

```cpp
// chrome/common/ads_messages.h
IPC_MESSAGE_START(AdsMsgStart)

// IPC_REVIEW: ✅ Reviewed in the Brave IPC checklist
// IPC_SECURITY: ✅ Message validated, no raw pointers
IPC_MESSAGE_ROUTED1(AdsMsg_Click, std::string /* ad_id */)

```

During continuous integration, the `ipc_security_check` script scans for the `IPC_REVIEW` comment and fails the build if security annotations are missing or if the message violates safety constraints.

### Enforcing Sandbox Restrictions for Renderer Processes

The following sandbox hook demonstrates how Brave applies additional capability restrictions to specific renderer types:

```cpp
// chrome/browser/sandbox/chrome_sandbox_hook_linux.cc
void ChromeSandboxHook::PreSandboxHook() {
  // Disallow network sockets for the ad-renderer (example)
  if (process_type == sandbox::policy::Sandbox::kRenderer &&
      command_line.HasSwitch("ad-renderer")) {
    policy->AddPolicy(sandbox::policy::NamespacePolicy::kNetwork,
                      sandbox::policy::NamespacePolicy::kNoAccess);
  }
}

```

This policy ensures that processes launched with the `--ad-renderer` flag lose network capabilities, preventing a compromised ad process from reaching the internet even if the IPC layer were breached.

## Key Files and Documentation

The following files define and enforce Brave's IPC security boundaries:

| File / Directory | Purpose | Location |
|------------------|---------|----------|
| [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md) (lines 186‑188) | Lists external security and IPC guidelines Brave follows | <https://github.com/brave/brave-browser/blob/master/README.md#L186-L188> |
| [`chrome/common/ipc_message_start.h`](https://github.com/brave/brave-browser/blob/main/chrome/common/ipc_message_start.h) | Central registry for IPC message identifiers and allow-list macros | <https://github.com/chromium/chromium/blob/main/chrome/common/ipc_message_start.h> |
| [`tools/ipc/ipc_security_check.py`](https://github.com/brave/brave-browser/blob/main/tools/ipc/ipc_security_check.py) | Automated static analysis enforcing the IPC review checklist | <https://chromium.googlesource.com/chromium/src/+/main/tools/ipc/ipc_security_check.py> |
| `chrome/browser/sandbox/*` | Per-process sandbox policies restricting IPC capabilities | <https://github.com/chromium/chromium/tree/main/chrome/browser/sandbox> |
| `chrome/browser/…/mojom/*.mojom` | Mojo interface definitions serving as capability contracts | <https://github.com/chromium/chromium/tree/main/chrome/browser> |
| External – Chromium IPC review guidelines | Detailed checklist for message validation and permissions | <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ipc-reviews.md> |
| External – Chromium security rules | General security coding standards for Chromium-based browsers | <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rules.md> |

## Summary

- Brave **inherits** Chromium's multi-process sandbox architecture and Mojo IPC system rather than implementing a separate security layer.
- All IPC messages must pass a **strict allow-list** and automated `ipc_security_check` validation before compilation.
- **Capability-based permissions** ensure Mojo interfaces expose only minimal required methods, preventing privilege escalation.
- **Process isolation** restricts system calls and resource access per process type, with additional Brave-specific sandbox policies.
- Security rules are documented transparently in [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md) lines 186-188, linking to Chromium's authoritative IPC review guidelines and security rules.

## Frequently Asked Questions

### How does Brave's IPC security differ from standard Chromium?

Brave adopts Chromium's proven Mojo IPC and sandbox mechanisms without re-implementing a separate layer. The primary difference lies in Brave's additional **review gates** and project-specific policies (such as ad-blocking and rewards integration) that must pass internal security checklists before merging, as referenced in the repository's [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md).

### What is the IPC review checklist and where is it enforced?

The **IPC review checklist** is a mandatory audit process derived from Chromium's security guidelines that requires every new IPC message to be validated for proper serialization, absence of raw pointers, and least-privilege design. This checklist is enforced automatically by the `ipc_security_check` build tool located in `tools/ipc/`, which scans for `IPC_REVIEW` comments and fails the build if security annotations are missing.

### Can renderer processes access high-privilege browser methods?

No. Brave implements **capability-based permissions** through Mojo interface definitions (`.mojom` files) that explicitly limit which processes can invoke specific methods. For example, a sandboxed `Renderer` process cannot invoke `Browser::DeleteAllCookies` because the interface binding restricts such high-privilege operations to trusted UI or browser processes only.

### Where are the authoritative security rules documented?

Brave's security model references external Chromium documentation linked directly in the repository's [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md) at lines 186-188. These links point to the official **[Chromium Security Rules](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rules.md)** and **[IPC Review Guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ipc-reviews.md)**, which serve as the authoritative standards for all IPC and sandbox implementations.