The browser security model

Security is several walls

A browser runs code from pages you did not build beside pages you did build. A shopping page, a bank, an ad, and an embedded video may all be open at once. The browser therefore uses several layers so code from one place cannot simply read the private data of another.

One layer does not replace the others. Origin checks decide whether script may directly inspect another origin's protected DOM or storage. Chrome Site Isolation adds a process boundary. Timer limits reduce a side channel. V8 adds engine hardening beneath the page level.

This follows Realms, globals & WindowProxy. A frame can have its own global object, but the browser still needs rules for what one frame may read from another. The next lesson, Load, link, evaluate, returns to module execution.

The same-origin policy

An origin is a URL's scheme, host, and port. The same-origin policy uses this tuple to restrict how a document or script from one origin interacts with protected resources from another origin. Paths do not change an origin.

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);

Line 1 creates an HTTPS URL. Line 2 creates another HTTPS URL with port 443 written explicitly. Line 3 prints true because 443 is HTTPS's default port. Line 5 prints false because HTTP changes the scheme. Line 6 prints false because api.shop.example changes the host.

The policy is not “nothing crosses origins.” A page can often navigate, submit a form, or embed selected resources across origins. What it cannot normally do is read protected cross-origin responses, DOM content, or origin-keyed storage. A server can grant selected reads with CORS, while windows can exchange intentional messages with postMessage.

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

Same site is broader than same origin. Browser policies often use a scheme plus registered domain boundary, while direct script access uses the stricter scheme-host-port origin tuple. Two subdomains can be same-site while still being different origins.

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));

Try the suggested URLs. The fixed first URL is https://shop.example/cart. Changing only the path keeps the origin. Changing to https://shop.example:443 keeps the normalized HTTPS port. Changing to HTTP or the API subdomain changes the origin.

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));

Line 1 parses the first URL and line 2 parses the second. Line 3 keeps only the last two host labels, then line 4 also checks the scheme. It prints true for the shop and API examples. This is a teaching model only: real browsers use the Public Suffix List, so “last two labels” is not a production site algorithm.

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));

Process-per-site and site isolation

The same-origin policy is a rule enforced in browser code. Browser vendors also use architecture to reduce the damage when a rule has a bug. In Chrome, Site Isolation places pages from different sites into different sandboxed renderer processes as an extra defense.

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");

Lines 1 and 2 name pages on two different sites. Lines 4 and 5 would both print false with the lesson models. Line 6 describes the Chrome-specific result: cross-site documents are placed in separate renderer processes, so one site's memory is not in another site's renderer process.

Chrome defines a site roughly as scheme plus registered domain, ignoring subdomains and ports for this process boundary. That is intentionally different from origin. It preserves web compatibility while still placing cross-site documents apart. The companion lesson Browser architecture explains browser, renderer, and sandbox roles in more depth.

Spectre and timer precision

Spectre is a family of CPU side-channel attacks. In plain words, careful timing can sometimes reveal information indirectly, rather than an ordinary JavaScript property access returning a secret. Browsers reduce that risk with several defenses, including isolation and less precise clocks in ordinary contexts.

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

Line 1 stores 0.005 milliseconds and line 2 stores 0.1 milliseconds. Lines 4 and 5 multiply by 1,000, so the snippet prints 5 and 100. MDN documents these as isolated and non-isolated timer resolutions. Say “in Chrome” when discussing the well-known 5-microsecond and 100-microsecond behavior, because browsers can vary their mitigations.

This is why a page should not assume performance.now() has one universal precision. Measure performance for product work, but do not build a security design that depends on counting microscopic time differences.

COOP, COEP, and cross-origin isolation

Cross-origin isolation is an opt-in browser state for a document and its browsing context group. It allows selected powerful APIs with fewer restrictions, while demanding stronger agreement about popups and embedded cross-origin resources.

1// HTTP response headers, set by the server.2Cross-Origin-Opener-Policy: same-origin3Cross-Origin-Embedder-Policy: require-corp4 5// Cross-origin resources must opt in with CORP or CORS.

Line 2 is COOP: same-origin keeps the document's browsing context group for compatible same-origin documents. Line 3 is COEP: require-corp blocks no-CORS cross-origin resources unless they explicitly allow embedding with CORP, or are loaded with CORS permission.

When the requirements are satisfied and Permissions Policy does not block it, crossOriginIsolated becomes true. That can unlock SharedArrayBuffer, more precise timers, and performance.measureUserAgentSpecificMemory(). These are capabilities to feature-detect, not promises that every browser offers every API.

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}

Line 1 converts the current environment into a boolean. Line 2 prints that boolean. The normal page path prints cross-origin isolated: false and then use an ordinary ArrayBuffer here. An isolated page with shared memory support prints the other message instead.

Adopting COEP can break third-party images, scripts, fonts, or iframes that did not opt in. Start with report-only tooling, inventory embedded resources, and ask each resource for CORS or CORP support. The published CORS and Windows and frames lessons provide the related page-level tools.

The V8 sandbox and JIT hardening

The V8 sandbox is an in-process security boundary in V8. Its basic aim is to keep V8 heap memory in a bounded region, so a memory-corruption bug in V8 has a harder time reaching the rest of the browser process. This is engine work beneath your page; JavaScript cannot turn it on with a header.

1// This is a conceptual summary, not runnable V8 source.2const protections = [3  "V8 heap stays inside a bounded sandbox region",4  "outside pointers use checked indirection",5  "JIT code pages are not writable and executable together",6];7 8console.log(protections.length);

Line 2 describes the heap boundary. Line 3 summarizes the checked indirection used for values that refer outside the sandbox. Line 4 names a separate JIT hardening rule: generated code pages are not writable and executable at the same time. Line 8 would print 3, but the code is a summary, not the V8 implementation.

JIT means just-in-time compilation: an engine can turn hot JavaScript into machine code while a program runs. Hardening makes it harder for a memory bug to rewrite executable code. The V8 sandbox is also not a cure for every V8 bug; it aims to contain the impact so escaping the heap needs another boundary failure.

Practical website decisions

Most application teams work directly with origins, CORS, frame messaging, and headers. They benefit from knowing the lower layers because a security report may mention a renderer process, a timer, or cross-origin isolation. But the first fix should match the actual boundary that is missing.

• Choose a separate origin for an application that needs a real security boundary, not just a separate route.
• Use postMessage with a specific target origin for intentional frame or popup communication.
• Use CORS only for servers that truly intend to share a response with another origin.
• Before enabling COEP, inventory cross-origin images, fonts, scripts, iframes, and workers.
• Feature-detect crossOriginIsolated and related APIs instead of assuming a browser state.

Common security-model misconceptions

• “Same site means scripts can read each other.” No. Direct protected access normally needs same origin.
• “CORS disables the same-origin policy.” No. It is a server-controlled exception for selected cross-origin reads.
• “COOP and COEP are JavaScript settings.” No. They are HTTP response headers sent before page JavaScript runs.
• “Site Isolation is a universal browser-process guarantee.” It is a Chrome security feature with platform and compatibility details.
• “A V8 sandbox means page bugs cannot matter.” It is one defense layer; secure page code and server checks still matter.

The useful habit is to ask two questions: what is the attacker trying to read or control, and which layer actually owns that boundary? That keeps a header fix, a CORS fix, and a process-isolation explanation from being mixed together.

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

Use the URL tuple for origin questions, then name the independent layer that handles processes, timers, response headers, or V8 heap corruption.

Key takeaways

• Same origin means the same scheme, host, and port; a path does not change an origin.
• Same site is broader and must not be confused with permission for direct script access.
• Chrome Site Isolation uses separate sandboxed renderer processes for different sites as defense in depth.
• Timer coarsening and isolation help reduce Spectre-style side-channel risk.
• COOP and COEP can opt a page into cross-origin isolation, which you should feature-detect with crossOriginIsolated.
• The V8 sandbox and JIT hardening protect a lower engine layer; they complement, not replace, origin policy.

Coming next: Load, link, evaluate. You will follow a module graph through the browser's three module phases.