Same-Origin Policy: Why Wallets Use a Separate Subdomain

This article has three layers:

1. Layer 1: The Intuition: The same building vs. different buildings
2. Layer 2: Real-World Use: Why big companies put user content on different domains
3. Layer 3: Principles and engineering key points: The difference between origin and site, and how much isolation is enough

Layer 1: The Intuition

1.1 What is "Same-Origin"

Pages with the same origin are like living in the same room: a script in one page can freely read and write the content of another page, send requests, and read localStorage. Pages from different origins live in different rooms and cannot see each other by default.

1.2 Why move out

Suppose a website's login page, blog, forum, and wallet are all under example.com, differing only by path. Then:

• The forum has an XSS vulnerability (e.g., a specific post can embed a script);
• This script runs within the example.com origin;
• It can read the same-origin wallet page and even secretly change the recipient address on the page.

By moving the wallet to wallet.example.com, the forum's script can no longer touch it. The vulnerability still exists, but it cannot harm the most valuable assets.

Layer 2: Real-World Use

• User content on independent domains: Google puts user-uploaded files on googleusercontent.com, and GitHub puts user content on githubusercontent.com. The reason is the same: if a user-uploaded HTML file executes a script, it can only run within an origin that contains "no sensitive data."
• Independent admin consoles: Many companies place their administrative backends on a separate domain or even an internal network, completely isolated from the main site facing users.
• Payment pages: Third-party payment forms are usually embedded in merchant pages as iframes, but since the iframe comes from the payment provider's own origin, the merchant page's scripts cannot read the card numbers inside.
• Cryptocurrency: Incidents where wallets and DeFi frontends were tampered with (see "The Bybit Incident and Frontend Integrity") have made people increasingly realize that "the signing page must be a clean, isolated, and auditable origin."

Layer 3: Principles and Engineering

3.1 What the Same-Origin Policy governs

3.2 The difference between origin and site

• origin: Protocol + Full Domain + Port. wallet.example.com and blog.example.com are different origins.
• site: Protocol + "Registrable Domain" (eTLD+1). They belong to the same site example.com.

There are two instances where calculations are based on site rather than origin, meaning subdomain isolation is not perfect:

1. Cookies: Brother subdomains can set cookies for Domain=example.com, affecting your subdomain. The countermeasure is using cookies with the __Host- prefix.
2. SameSite: A request from blog.example.com to wallet.example.com is considered "same-site," so SameSite cannot block it. The countermeasure is for the server to verify the Origin header.

Extremely sensitive applications will simply use a completely different registrable domain, separating even the sites.

3.3 Isolation is not just for the browser

If the frontend moves to a separate origin, the backend must be isolated accordingly; otherwise, it is just changing the address label:

• Independent service processes and system users, independent databases and key files (see "Least Privilege and Key Management");
• Independent sessions that do not share cookies with the main site;
• The frontend is hosted on a platform unrelated to the main site's server: if the main site server is compromised, the attacker also cannot modify this page.

3.4 Stronger isolation headers

Summary