核心 · Key Idea
一句话:Cookie 是浏览器自动带在请求里的小数据包;CORS 是浏览器对"跨域请求"的安全策略;CSRF 是利用浏览器自动带 cookie 这一行为的攻击。三者总被混在一起,搞清各自管什么 = 90% 的网络安全 bug 不再发生。
Cookie#
Set-Cookie: session=abc; Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600Domain / Path作用范围
决定 cookie 会被发送到哪些请求里。
HttpOnly禁 JS 读
JS 读不到 → 防 XSS 偷会话。
Secure仅 HTTPS
只在 https 请求里发送。
SameSite同站策略
Strict / Lax(默认)/ None。控制跨站请求是否带上。**SameSite=Lax 是现代防 CSRF 第一道墙**。
__Host-前缀
强制 Secure + Path=/ + 无 Domain,最严的 cookie 类别。
CORS(Cross-Origin Resource Sharing)#
CORS 是浏览器的策略:默认禁止 JS 读跨域响应。服务器要明确用响应头同意才能放行。
# 简单请求
GET /api Origin: https://app.com
→ Access-Control-Allow-Origin: https://app.com
# 复杂请求先发 OPTIONS preflight
OPTIONS /api Origin: https://app.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Auth
→ Access-Control-Allow-Origin: https://app.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Auth
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600重点:CORS 不是为了保护服务器,是浏览器保护用户。你后端用 curl 永远不需要 CORS 头。
CSRF(跨站请求伪造)#
经典场景:
你登录了 bank.com,cookie 还在
→ 你打开 evil.com,里面有 <img src="https://bank.com/transfer?to=eve&amount=1000">
→ 浏览器自动带上 bank.com cookie 发请求
→ 银行执行转账(如果没防)
防御(按现代优先级):
SameSite=Lax/Strictcookie —— 跨站请求不带 cookie,从根上断。- CSRF token —— 服务端在表单里塞一个一次性 token,跨站攻击者拿不到。
- Double-submit cookie —— 头部 + cookie 同步比对,无服务端状态。
- 检查 Origin / Referer 头作为补充。
- 修改类操作不接受 GET —— GET 永远不应该改状态。
三者关系#
实操要点#
- 登录态用 HttpOnly + Secure + SameSite=Lax cookie。不要把 token 放 localStorage(XSS 即丢号)。
- CORS 配置最常见误区:
Allow-Origin: *+Allow-Credentials: true—— 浏览器会拒绝。带凭据时必须明确 origin。 - OPTIONS 预检失败 = CORS 错误:开发者面板里看清是哪一条响应头不齐 / origin 不匹配。
- API 子域分离 cookie:
api.example.com和www.example.com共享.example.com顶域 cookie 时,明确Domain=.example.com。 - 跨设备 SSO:跨顶域必须走 OAuth / SAML,不能靠 cookie。
- API 服务给原生 App / 服务器端调用 —— 不依赖浏览器 → CORS / CSRF 概念都不适用,但仍需身份认证(API Key / OAuth / mTLS)。
易混点#
CORS
浏览器**主动限制**跨域读响应。
管"我能不能拿到数据"。
管"我能不能拿到数据"。
CSRF
攻击者**利用**自动带 cookie。
管"我会不会被冒充提交"。
管"我会不会被冒充提交"。