Glittering's blog

Appearance

一、同源策略（Same-Origin Policy）⭐⭐⭐⭐⭐ ​

1️⃣ 什么是“源（Origin）” ​

  • 协议 + 域名 + 端口 三者完全相同
text
https://example.com:443

只要有一个不同，就 不同源

URL是否同源
https://example.com/a✅
http://example.com❌（协议）
https://sub.example.com❌（域名）
https://example.com:8080❌（端口）

2️⃣ 同源策略限制了什么？ ​

❌ 被限制的（重点） ​

1️⃣ DOM 访问

js
iframe.contentWindow.document // 不同源直接报错

2️⃣ Cookie / LocalStorage / IndexedDB

  • 不能读
  • 不能写

3️⃣ AJAX 读取响应

js
fetch('https://api.com') // 请求发得出，结果读不到

⚠️ 注意：请求本身是能发出去的！

✅ 不受限制的 ​

行为说明
<img src>常见打点
<script src>JSONP 基础
<link>CSS
<iframe>只是不能访问内容

3️⃣ 为什么要有同源策略？ ​

一句话：

  • 防止恶意网站读取你在其他网站的隐私数据

如果没有同源策略：

  • A 网站可直接读 B 网站的 Cookie
  • 银行 / 邮箱直接被拖库

4️⃣ 面试必考一句话版 ​

  • 同源策略是浏览器的一种安全机制，用来限制不同源之间的资源访问，防止恶意网站窃取用户数据。

二、CORS（跨域资源共享）⭐⭐⭐⭐⭐ ​

  • CORS 是“后端主动开门”让前端跨域

不是前端技术，是 浏览器 + 服务器协商规则

1️⃣ 为什么需要 CORS？ ​

因为：

  • 同源策略 限制读
  • 但现代前端必须跨域调 API

2️⃣ 简单请求 vs 预检请求（超高频） ​

✅ 简单请求（不会触发预检） ​

满足 全部条件：

  • 方法：GET / POST / HEAD

  • Content-Type：

    • text/plain
    • application/x-www-form-urlencoded
    • multipart/form-data

  • 没有自定义头

js
fetch('https://api.com/data')

🚨 非简单请求 → 预检（OPTIONS） ​

js
fetch('https://api.com/data', {
  method: 'PUT',
  headers: {
    'X-Token': 'xxx'
  }
})

浏览器先发：

http
OPTIONS /data
Origin: https://web.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Token

服务器回应：

http
Access-Control-Allow-Origin: https://web.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: X-Token

通过后才真正发请求

3️⃣ CORS 常见响应头（必须背） ​

http
Access-Control-Allow-Origin: https://web.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, X-Token
Access-Control-Allow-Methods: GET, POST

⚠️ 致命组合 ​

http
Allow-Origin: *
Allow-Credentials: true ❌

浏览器直接拒绝

4️⃣ Cookie 跨域的正确姿势 ​

前端 ​

js
fetch(url, {
  credentials: 'include'
})

后端 ​

http
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://web.com
Set-Cookie: sid=xxx; SameSite=None; Secure

5️⃣ CORS 面试高频坑 ​

❓ 为什么我已经允许跨域，还是报错？

👉 常见原因：

  • 预检请求没处理 OPTIONS
  • 忘了返回 Allow-Headers
  • 用了 * + credentials
  • 实际响应没带 CORS 头（只在 OPTIONS 带了）

三、CSP（内容安全策略）⭐⭐⭐⭐⭐ ​

  • CSP 是用来防 XSS 的终极武器

1️⃣ CSP 在干什么？ ​

一句话：

  • 限制页面“能加载 / 能执行”的资源来源

2️⃣ 基本写法 ​

http
Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  img-src 'self' https:;

含义：

  • 所有资源默认只允许自己
  • JS 只能来自自己
  • 图片允许 https

3️⃣ CSP 能防什么？ ​

攻击是否能防
XSS✅
eval 注入✅
第三方脚本投毒✅
CSRF❌

4️⃣ CSP 的关键指令（必会） ​

script-src ​

http
script-src 'self' 'nonce-abc123'
html
<script nonce="abc123">合法脚本</script>

禁用危险行为 ​

http
script-src 'self';
object-src 'none';
base-uri 'none';

5️⃣ CSP Report（生产必用） ​

http
Content-Security-Policy-Report-Only:
  default-src 'self';
  report-uri /csp-report

👉 只上报不拦截，防止误杀

6️⃣ 框架 + CSP 实战注意 ​

Vue / React ​

  • 禁止 eval（影响 devtool）
  • inline script 需要 nonce
  • 动态插 script 要配合 nonce

四、三者关系一张图（面试最加分） ​

同源策略：默认全禁
     ↓
CORS：服务器放行“读”
     ↓
CSP：限制“能执行什么”

五、终极总结 ​

  • 同源策略是浏览器的基础安全机制，限制不同源之间的资源访问；
  • CORS 是服务器通过响应头声明哪些跨域请求可以被浏览器读取；
  • CSP 是通过白名单机制限制页面可执行资源，用来防御 XSS 等注入攻击。

Copyright © 2026