Cookie 认证

Session Cookie 把 会话 ID 存在浏览器，服务器（或 Redis）存登录态——经典 有状态 模型。与 Bearer JWT 相对，Cookie 由浏览器 自动附带，因此必须正确设置 HttpOnly、Secure、SameSite，否则 XSS / CSRF / 中间人 都会打到会话。协议细节见 http-cookies。

学习目标

• 解释 Set-Cookie 各属性对安全的影响
• 在 Spring Session / Security 中配置安全 Cookie
• 选择 Cookie 会话 vs Token 的适用场景

典型流程

1. POST /login（HTTPS）→ 校验密码（sec-hash）
2. 响应 Set-Cookie: SESSION=...; HttpOnly; Secure; SameSite=Lax
3. 后续请求浏览器自动 Cookie: SESSION=...
4. 服务端查 session 得 userId

密码只在登录传一次；之后 不传密码，传 session id。

安全属性

属性	作用
HttpOnly	JS document.cookie 读不到 → 降 XSS 偷会话
Secure	仅 HTTPS 发送 → 需 sec-ssl
SameSite	跨站请求是否带 Cookie → 防 CSRF
Path / Domain	缩小 Cookie 生效范围
Max-Age / Expires	会话寿命； idle timeout 服务端也要做

SameSite 取值

值	行为	场景
Strict	跨站导航不带 Cookie	高安全后台
Lax	顶级 GET 导航可带	多数站点默认
None	跨站都带	需 Secure；嵌入式 / 跨域 SSO

OAuth 跨域回调常踩 SameSite 与 第三方 Cookie 淘汰——与 oauth-flows 一并规划。

CSRF 与 Cookie

Cookie 自动发送 → 恶意站点可诱使用户浏览器 带 Cookie 发 POST。

防御组合：

1. SameSite=Lax/Strict（现代浏览器）
2. CSRF Token（Spring Security 默认表单场景）