The browser security model

Security is several walls

A browser runs code from many websites at the same time. You may have a shop, your bank, an advert, and a video open together. You did not write most of that code. So the browser must keep each website's code away from the other websites' private data.

It does this with several walls, not one. If one wall has a hole, the next wall still stands.

Each wall works at a different level. One wall does not replace another. This lesson goes through them one at a time.

This lesson follows Realms, globals & WindowProxy. There you saw that each frame has its own global object. Here you will see the rules for what one frame may read from another. The next lesson, Load, link, evaluate, goes back to how modules run.

The same-origin policy

An origin is the first three parts of a web address (a URL):

• The scheme, like https.
• The host, like shop.example.
• The port, like 443. A port is a numbered door on the server. If an address shows no port, https uses 443 and http uses 80.

The path, like /cart, is not part of the origin. Two addresses have the same origin only when all three parts match.

The same-origin policy is the browser rule built on this. JavaScript from one origin cannot read the page, the saved data, or the server replies of another origin.

The code below uses two tools. new URL(text) turns an address string into a URL object. The object's origin property is a string with just the scheme, host, and port, like "https://shop.example".

1const a = new URL("https://shop.example/cart");2const b = new URL("https://shop.example:443/checkout");3console.log(a.origin === b.origin);4 5console.log(a.origin === new URL("http://shop.example").origin);6console.log(a.origin === new URL("https://api.shop.example").origin);

In plain words, line by line:

1. Line 1 makes a URL for the shop's cart page.
2. Line 2 makes a URL for the checkout page. It writes the port, 443, out in full.
3. Line 3 prints true. 443 is the port https uses anyway, so the origins match. The different paths do not count.
4. Line 5 prints false. http is a different scheme from https.
5. Line 6 prints false. api.shop.example is a different host from shop.example.

The policy does not block everything between origins. A page can still link to another origin, send a form to it, or show its images. What it cannot do is read another origin's protected things:

• its page content (the DOM),
• its saved data (storage, like localStorage),
• its server replies, unless that server agrees.

When two origins want to share on purpose, there are two safe tools. CORS lets a server say "this other origin may read my reply". postMessage lets two windows send each other messages.

1const first = "https://shop.example/cart";Run2const second = "https://shop.example:443/checkout";3 4function sameOrigin(first, second) {5  const a = new URL(first);6  const b = new URL(second);7  return a.protocol === b.protocol &&8    a.hostname === b.hostname &&9    a.port === b.port;10}11 12console.log(sameOrigin(first, second));

Same origin and same site answer different questions

A site is a bigger group than an origin. Roughly, it is the scheme plus the main domain name: the part an owner registers, like shop.example. Two addresses are the same site when those match.

So shop.example and api.shop.example are the same site. They are still different origins, because their hosts are different. The browser uses "same site" for some rules, like when to send cookies. It uses the stricter "same origin" to decide whether a script may read another page.

1function sameOrigin(first, second) {2  const a = new URL(first);3  const b = new URL(second);4  return a.protocol === b.protocol &&5    a.hostname === b.hostname &&6    a.port === b.port;7}8 9console.log(sameOrigin(10  "https://shop.example/cart",11  "https://shop.example:443/checkout",12));

The first address stays https://shop.example/cart. You change the second one. Try these:

• Change only the path. The origin stays the same.
• https://shop.example:443: still the same origin, because https uses 443 anyway.
• http://shop.example: a different origin, because the scheme changed.
• https://api.shop.example: a different origin, because the host changed. It is still the same site.

Here is a small model of "same site", written for this lesson.

1function sameSite(first, second) {2  const a = new URL(first);3  const b = new URL(second);4  const site = (url) => url.hostname.split(".").slice(-2).join(".");5  return a.protocol === b.protocol && site(a) === site(b);6}7 8console.log(sameSite(9  "https://shop.example/cart",10  "https://api.shop.example/orders",11));

In plain words, line by line:

1. Line 1 starts a function, sameSite, that takes two addresses.
2. Line 2 turns the first address into a URL object.
3. Line 3 does the same for the second address.
4. Line 4 makes a small helper, site. It keeps only the last two parts of the host. split(".") cuts the host at each dot, slice(-2) keeps the last two pieces, and join(".") glues them back. So api.shop.example becomes shop.example.
5. Line 5 returns true when the schemes match and the two short hosts match.

Lines 8 to 11 call it with the shop address and the API address. It prints true.

Real browsers do not just keep the last two parts. Some endings, like co.uk, are shared by many different owners. So browsers use a list of these shared endings, called the Public Suffix List. Use this model only for learning, never in real code.

The table below compares three terms. Each row names one term. Read across to see what must match and which question the term answers.

1const first = "https://shop.example/cart";Run2const second = "https://api.shop.example/orders";3 4function sameSite(first, second) {5  const a = new URL(first);6  const b = new URL(second);7  const site = (url) => url.hostname.split(".").slice(-2).join(".");8  return a.protocol === b.protocol && site(a) === site(b);9}10 11console.log(sameSite(first, second));

Separate processes for separate sites

The same-origin policy is a rule, and browser code checks it. But browser code can have bugs. So browsers add a second wall that does not depend on that check.

A process is a running program with its own memory. One process cannot read another process's memory. A renderer process is the process that draws a page and runs its JavaScript.

Chrome has a feature called Site Isolation. It puts pages from different sites into different renderer processes. Each of these processes also runs in a sandbox: it is locked down, so it cannot touch your files or other programs directly.

1const page = "https://shop.example";2const frame = "https://news.example";3 4console.log("same site?", sameSite(page, frame));5console.log("same origin?", sameOrigin(page, frame));6console.log("Chrome isolates cross-site pages in separate renderer processes");

This code uses the sameSite and sameOrigin functions from earlier in the lesson, so it is shown here without a Run button.

1. Line 1 names a page on shop.example.
2. Line 2 names a frame on news.example.
3. Line 4 prints same site? false. The main domain names are different.
4. Line 5 prints same origin? false. The hosts are different.
5. Line 6 only prints a sentence. JavaScript cannot check processes. The sentence says what Chrome does.

For this wall, Chrome groups pages by site, not by origin. It ignores subdomains and ports. Some older websites let pages on two subdomains of one site work with each other directly. To keep those websites working, Chrome keeps one site's pages together. Pages from different sites still end up apart. The lesson Browser architecture explains the browser process, renderer processes, and sandboxes in more depth.

Spectre and less exact timers

Spectre is a kind of attack on the computer's processor (the CPU). The attacker never reads the secret directly. Instead, the attacker measures how long tiny steps take. Small differences in time can give away pieces of data.

This is called a side channel: the secret leaks out through a side effect, here time, instead of through a normal read. Browsers fight it in two ways:

• They keep different sites in separate processes.
• They make timers less exact on normal pages.

1const isolatedResolution = 0.005;2const regularResolution = 0.1;3 4console.log("isolated context microseconds:", isolatedResolution * 1000);5console.log("regular context microseconds:", regularResolution * 1000);

In plain words, line by line:

1. Line 1 stores 0.005 milliseconds: the smallest timer step on an isolated page.
2. Line 2 stores 0.1 milliseconds: the smallest timer step on a normal page.
3. Lines 4 and 5 multiply by 1,000. That turns milliseconds into microseconds (millionths of a second). They print 5 and 100.

MDN, the main reference site for web developers, lists these two numbers. They are what Chrome does. Other browsers can choose different numbers. "Isolated" here means cross-origin isolated; you will meet that in the next section.

performance.now() gives the time in milliseconds since the page started. Do not expect it to be equally exact everywhere. It is fine for measuring how fast your code runs. But do not build security that depends on tiny time differences.

COOP, COEP, and cross-origin isolation

Cross-origin isolation is a stronger state that a page can ask for. It is off unless the page asks. In return, the page may use a few powerful tools that are too risky on normal pages.

To ask for it, the server sends two response headers. A response header is a short line of text the server sends along with the page, before the page's content.

1// Response headers. The server sends them with the page.2Cross-Origin-Opener-Policy: same-origin3Cross-Origin-Embedder-Policy: require-corp4 5// Files from other origins must agree, with CORP or CORS.

In plain words, line by line:

1. Line 1 is a note: the server sets these headers.
2. Line 2 is COOP, short for Cross-Origin-Opener-Policy. With same-origin, a popup window from another origin can no longer reach this page, and this page cannot reach it. Only windows from the same origin stay connected.
3. Line 3 is COEP, short for Cross-Origin-Embedder-Policy. With require-corp, the page may load a file from another origin (an image, script, font, or frame) only if that file agrees.

A file agrees in one of two ways. It sends its own CORP header (Cross-Origin-Resource-Policy) saying other origins may use it. Or the page loads it with CORS, and its server allows that. Line 5 is a note that says the same thing.

When both headers are set, the browser sets a global variable, crossOriginIsolated, to true. One more header, the permissions policy, can turn features off; it must not block this one. A true value can unlock these tools:

• SharedArrayBuffer: memory that two threads can use at the same time.
• More exact timers.
• performance.measureUserAgentSpecificMemory(): a way to measure how much memory the page uses.

Not every browser has every one of these tools. So check that a tool exists before you use it. This is called feature detection.

1const isolated = globalThis.crossOriginIsolated === true;2console.log("cross-origin isolated:", isolated);3 4if (isolated && "SharedArrayBuffer" in globalThis) {5  console.log("shared memory is available");6} else {7  console.log("use an ordinary ArrayBuffer here");8}

In plain words, line by line:

1. Line 1 reads crossOriginIsolated from globalThis, the global object. The === true turns it into a plain true or false, even if the variable does not exist.
2. Line 2 prints that value.
3. Line 4 checks two things: the page is isolated, and SharedArrayBuffer exists.
4. Line 5 runs only when both are true.
5. Line 7 runs in every other case. It uses a normal ArrayBuffer: memory for one thread only.

On a normal page, it prints cross-origin isolated: false and then use an ordinary ArrayBuffer here.

Turning on COEP can break a page. Images, scripts, fonts, or frames from other origins stop loading if they do not agree. So go step by step:

1. Start in report-only mode. The browser then only reports what would break, and blocks nothing.
2. List every file your page loads from other origins.
3. Ask each one to send CORP, or load it with CORS.

The CORS and Windows and frames lessons show the related tools for pages.

Walls inside the JavaScript engine

V8 is the JavaScript engine in Chrome: the program that runs your JavaScript. V8 itself is written in C++. A bug in V8 can let an attacker write over memory they should never touch. This is called memory corruption.

The V8 sandbox is a wall inside V8. V8 keeps its heap, the memory where JavaScript objects live, inside one fenced-off region. If a bug corrupts memory there, it is hard to reach memory outside the region. This all happens inside the engine. Your page cannot turn it on or off, and no header controls it.

1// A short summary in plain words, not real V8 code.2const protections = [3  "V8 objects stay inside one fenced-off memory region",4  "addresses outside the region go through a checked table",5  "machine code is never writable and runnable at once",6];7 8console.log(protections.length);

In plain words, line by line:

1. Line 1 is a note: this is a summary, not real V8 code.
2. Line 2 starts a list of three walls.
3. Line 3: V8's objects stay inside a fenced-off memory region.
4. Line 4: when something in the region points to memory outside it, V8 looks the address up in a checked table. It never follows a raw address.
5. Line 5: memory that holds machine code made while the program runs can be written, or run, but never both at the same time.

Line 8 would print 3, the number of items in the list.

Line 5 needs one more word. JIT is short for just-in-time compiling. While your program runs, V8 turns busy JavaScript into machine code, the CPU's own instructions, to make it faster. If an attacker could write into that machine code, they could make the CPU do anything. So V8 never lets that memory be writable and runnable at once. This is called JIT hardening.

The V8 sandbox does not stop every V8 bug. It makes one bug not enough. To escape the region, an attacker needs a second bug that breaks another wall.

What this means for your website

Most web developers work with origins, CORS, messages between windows, and headers. Browser makers build the lower walls: processes, timers, and the V8 sandbox. It still helps to know them, because a security report may mention a renderer process, a timer, or cross-origin isolation. First find which wall is missing. Then pick the fix for that wall.

• If an app needs a real wall around it, give it its own origin, like its own subdomain. A different path, like /admin, is the same origin, so it is not a wall.
• To talk to another window or frame, use postMessage and name the exact origin that may receive the message.
• Turn on CORS only on a server that really wants another origin to read its replies.
• Before you turn on COEP, list every image, font, script, frame, and worker your page loads from other origins.
• Check crossOriginIsolated, and check that each tool exists, instead of guessing what the browser supports.

The table below lists the walls. Each row is one wall. Read across to see what it stops and what you, the developer, do about it.

Common mistakes about browser security

• "Pages on the same site can read each other." No. To read another page directly, a script normally needs the same origin, not just the same site.
• "CORS turns off the same-origin policy." No. CORS lets one server allow certain other origins to read its replies. Everything else stays blocked.
• "COOP and COEP are JavaScript settings." No. They are response headers. The server sends them before any of the page's JavaScript runs.
• "Every browser puts every site in its own process." No. Site Isolation is a Chrome feature, and how it works depends on the device and the platform.
• "The V8 sandbox means bugs in my page do not matter." No. It is one wall inside the engine. Your page code and your server checks still need to be safe.

The table below lists terms that people often mix up. Read across each row: what the term means, and what it is not.

When you look at a security problem, ask two questions:

1. What is the attacker trying to read or control?
2. Which wall is meant to stop that?

Then you will not use a header to fix a CORS problem, or blame a process for an origin problem.

Practice exercises

const a = new URL("https://shop.example/cart");
const b = new URL("https://shop.example:443/checkout");
console.log(a.origin === b.origin);

const secure = new URL("https://shop.example");
const plain = new URL("http://shop.example");
console.log(secure.origin === plain.origin);

const shop = new URL("https://shop.example");
const api = new URL("https://api.shop.example");
console.log(shop.origin, api.origin);

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

const isolated = false;
console.log(isolated ? "use SharedArrayBuffer" : "use ArrayBuffer");

Check your understanding

For each question, first decide which wall it is about. Questions about addresses are about origins. The others are about processes, timers, response headers, or memory bugs in V8.

Key takeaways

• Two addresses have the same origin when the scheme, host, and port all match. The path does not count.
• Same site is a bigger group. It does not let scripts read each other's pages.
• In Chrome, Site Isolation runs different sites in separate processes, as an extra wall.
• Less exact timers and separate processes make Spectre-style timing attacks harder.
• The COOP and COEP headers can make a page cross-origin isolated. Check crossOriginIsolated before you use tools that need it.
• The V8 sandbox and JIT hardening protect the engine itself. They add to the same-origin policy; they do not replace it.

Coming next: Load, link, evaluate. You will follow a group of modules through the three steps the browser uses to run them.