Scheme-restricted URL types for Mojo IPC: url.mojom.HttpsUrl

3 views
Skip to first unread message

Tanishk Tiwari

unread,
Apr 15, 2026, 12:55:41 PMApr 15
to dch...@chromium.org, mk...@chromium.org, site-isol...@chromium.org, platform-arc...@chromium.org, Fayez Razak, Gareth Evans, Kevin Babbitt
Hi everyone,

We are proposing a new Mojo type, url.mojom.HttpsUrl, to enforce HTTPS-only invariants directly at the IPC deserialization boundary.

This acts as a drop-in replacement for url.mojom.Url in .mojom files while continuing to map to GURL in C++. The goal is to catch scheme violations at the earliest point a URL crosses a trust boundary, preventing compromised renderers from exploiting missing ad-hoc checks in the browser process.

The Issue

Currently, Mojo interfaces that require HTTPS URLs must implement manual scheme checks in C++. This creates several risks:
  • It is easy to forget a SchemeIs("https") check, leading to logic bugs where a compromised renderer can use unintended schemes to escalate privileges (e.g. crbug.com/40057925).
  • The invariant is checked inconsistently across dozens of files (e.g., SchemeIs(kHttpsScheme), or just DCHECKs).
  • Reading a .mojom file provides no static visibility into whether a URL field expects HTTPS-only, HTTP-or-HTTPS, or any scheme.

Our Proposal

We introduce url.mojom.HttpsUrl:

// Before: Scheme contract is implicit; validation relies on ad-hoc C++ code. struct InterestGroup {  url.mojom.Url bidding_url; }; // After: HTTPS enforced automatically at deserialization. struct InterestGroup {  url.mojom.HttpsUrl bidding_url; }
  1. If the deserialized URL's scheme is not https, validation fails and triggers a BadMessageReceived().
  2. The C++ representation still maps to GURL so feature code doesn't need to adopt a new C++ type.

Scope

An analysis of existing url.mojom.Url usages across the codebase shows:
  • ˜50 usages strictly require HTTPS today (e.g., Protected Audience Worklets, Oblivious HTTP).
  • ˜37 usages require HTTP/HTTPS or a Secure Context.

By migrating those 50 strict-HTTPS usages to url.mojom.HttpsUrl, we codify the invariant in the interface and get to cleanup ad-hoc C++ checks. 

We are scoping this initial proposal to strict-HTTPS for now, but the general pattern is extensible - we can introduce HttpOrHttpsUrl or SecureContextUrl in the future if there is demand.


Would love to hear your thoughts and get feedback!

Tanishk
Microsoft Edge Security

Tanishk Tiwari

unread,
Apr 17, 2026, 12:00:47 PM (13 days ago) Apr 17
to dch...@chromium.org, mk...@chromium.org, site-isol...@chromium.org, platform-arc...@chromium.org, Fayez Razak, Gareth Evans, Kevin Babbitt
Hello, 

Bumping this up, in case this got lost earlier 😊

Reply all
Reply to author
Forward
0 new messages