1. Overview of browser security models (overview of the overall situation first)

Think of the browser as a sandbox operating system:

用户数据（Cookie / 本地文件 / 摄像头）
        ↑
   浏览器安全边界
        ↑
网页 JS（不可信）

Three sentences of core goals:

• 1️⃣ Web pages cannot attack each other
• 2️⃣ Web pages cannot access user privacy and system resources at will
• 3️⃣ When a vulnerability occurs, the scope of impact should be as small as possible

2. Core security boundary (most frequently asked in interviews)

1️⃣Origin-based Isolation

This is the most basic security boundary of the browser.

Restricted objects

• DOM
• Cookie / Storage
• JS execution environment

不同 Origin = 不同安全域

Why not "domain name"?

Because:

• Different protocols (http/https) have different security levels
• Different ports → may be different services

2️⃣ Process Isolation ⭐⭐⭐⭐⭐

The most important security upgrade for modern browsers

Early (unsafe)

• Multiple pages share one process
• Ordinary XSS remains constrained by the same-origin policy; shared processes increase cross-site risk after renderer compromise or side-channel exploitation.

Modern browsers (represented by Chrome)

• Site Isolation
• One site ≈ one rendering process

Browser Process
 ├── Renderer (site A)
 ├── Renderer (site B)
 └── Network Process

Benefits

• Even if JS is compromised, it is still trapped in the process
• Prevent Specter hardware vulnerabilities

3️⃣ Sandbox ⭐⭐⭐⭐⭐

JS ≠ system permissions

What can JS do?

• ✅ Manipulate DOM
• ✅ Send network request
• ❌ Read file system
• ❌Access system API
• ❌ Execute local program

Ground floor

• OS-level sandbox
• seccomp / AppContainer / seatbelt

3. Resource access control model

1️⃣ Network request model

JS sends request

fetch(url)

Limitations:

• Same Origin Policy (Read Response)
• CORS (server release)
• Mixed Content (HTTPS pages cannot request HTTP)

2️⃣ Cookie security model

Set-Cookie:
  HttpOnly;
  Secure;
  SameSite

The function of each field

Field	What to guard against
HttpOnly	Prevents script access to cookies, not XSS execution or authenticated requests
Secure	Sends cookies only over secure connections
SameSite	Restricts cross-site cookies as part of CSRF protection

3️⃣ Storage isolation

Storage	Isolation Dimensions
localStorage	origin
sessionStorage	tab + origin
IndexedDB	origin

The same-origin policy restricts cross-origin iframe DOM access; controlled postMessage communication remains possible. Cookies are not isolated by port.

4. Code execution security (JS execution model)

1️⃣ JS is single-threaded, but not single-environment

Main Thread
 ├── JS
 ├── DOM
 └── Layout

Why is it important?

• blocking ≠ safe
• Worker execution environment is cleaner

2️⃣ Web Worker Security

Capabilities	Allowed
DOM	❌
Cookie	❌
fetch	✅
postMessage	✅

👉 Worker is an isolated computing sandbox

3️⃣ eval / new Function (high risk)

Reason:

• Bypass static analysis
• CSP can block eval / new Function; unsafe-eval weakens that restriction.
• Perform user input

eval(userInput) // ❌

5. Cross-document communication security (postMessage)

Correct usage (high-frequency test points)

window.addEventListener('message', e => {
  if (e.origin !== 'https://trusted.com') return
})

Error example

window.addEventListener('message', e => {
  // 不校验 origin
})

6. Permissions Model (Permissions API)

Browser sensitive capabilities explicit authorization:

Capabilities	Whether to pop up a window
Camera	✅
Microphone	✅
Positioning	✅
Clipboard	Section

👉 And it is:

• by site
• Can be revoked at any time

7. HTTPS and transmission security

Why is HTTPS part of the security model?

No HTTPS:

• Same origin policy ≈ invalid
• Cookies can be hijacked
• CSP can be tampered with

HSTS

Strict-Transport-Security: max-age=31536000

8. The “position” of common attacks in the security model

Attack	Which level to break through
XSS	JS execution layer
CSRF	Cookie automatically sent
Clickjacking	UI Layer
Specter	Process Isolation
Supply Chain Attacks	Executing the Chain of Trust

9. The ultimate summary of the interview “security model”

• The browser security model limits untrusted web page code to the minimum permissions through the same-origin policy, process isolation, and sandbox mechanisms; it also combines CORS, CSP, permission systems, and HTTPS to prevent data leaks, code injection, and unauthorized access.