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 默认表单场景）
3. 双重 Cookie 或 自定义头（SPA 常用 X-XSRF-TOKEN）
4. 敏感操作 再验证（密码、2FA）

纯 JWT 在 Header、不用 Cookie 的 API，CSRF 风险 低——但 XSS 偷 token 仍致命（sec-csp）。

Spring Boot 配置示例

server:
  servlet:
    session:
      cookie:
        http-only: true
        secure: true
        same-site: lax
        name: SESSION

Spring Security：

http.sessionManagement(s -> s
    .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
    .maximumSessions(1)); // 可选：单点登录控制

集群部署用 Spring Session Redis 存 session，避免 sticky session 单点。

Cookie vs Bearer：怎么选

	Cookie 会话	Bearer JWT
自动附带	是	否，JS 显式加头
XSS	HttpOnly 保护 session id	token 常在 JS 可见
CSRF	需 SameSite + token	较低
移动原生 App	不自然	更自然
注销	服务端删 session 即失效	需黑名单或短 exp

BFF 模式：浏览器只持 Cookie，BFF 换 内网 JWT 调 API——兼顾安全与 SPA 体验。

与 sec-auth-basic 对比

Basic 每次 上传密码；Cookie 一次登录 后只传 session id——但仍要 HTTPS 与固定会话管理。

练习

• DevTools → Application → Cookies，检查本地项目 Cookie 四个属性
• 说明：为何 HttpOnly 不能防 CSRF
• 阅读 http-cookies，对比本文 SameSite 表

小结

Cookie 会话靠 HttpOnly + Secure + SameSite；CSRF 要单独防。 下一课企业 SSO：SAML 与 OIDC 对比。