Cookie 安全属性检查
检查会话 Cookie 的 Secure、HttpOnly、SameSite 等属性是否齐全，定位 XSS 与 CSRF 的暴露面。
Cookie 属性检查
按行分析，每行一个 Cookie。判断依据为常见安全基线，具体以业务实际为准。
四个属性分别管什么
Secure 限定 Cookie 只在 HTTPS 连接中发送。缺少这个属性时，用户在 HTTP 页面上的任何一次请求都会把 Cookie 明文发出去，在公共网络环境下等同于把会话凭证交出去。会话类 Cookie 必须加上。
HttpOnly 让 Cookie 无法被 JavaScript 读取。这是防 XSS 窃取会话的最后一道闸门——即使页面被注入脚本，脚本也拿不到会话 Cookie。会话类 Cookie 必须加上。
SameSite 控制跨站请求是否携带 Cookie，是防 CSRF 的主要手段。Strict 最严格，任何跨站请求都不带；Lax 允许顶层导航的 GET 请求携带，是当前浏览器的默认值；None 表示不限制，但必须同时加 Secure。
Domain 和 Path 决定作用域。Domain 写得过宽会让 Cookie 被更多子域共享，一旦某个子域存在漏洞，主域会话就可能被利用。Path 设为根路径同样会扩大暴露面。
前缀约定
__Secure- 前缀要求 Cookie 必须带 Secure 属性；__Host- 前缀要求同时满足 Secure、Path=/ 且不带 Domain。这两个前缀由浏览器强制校验，能防止子域覆盖主域 Cookie。
常见配置与风险对照
| 配置 | 主要风险 | 建议 |
|---|---|---|
| 无 Secure | HTTP 请求明文发送，可被中间人截获 | 会话 Cookie 加上 Secure |
| 无 HttpOnly | XSS 注入后可读取会话凭证 | 会话 Cookie 加上 HttpOnly |
| 无 SameSite | 依赖浏览器默认值，跨站请求可能携带 | 显式设为 Lax 或 Strict |
| SameSite=None 但无 Secure | 浏览器会直接拒绝该 Cookie | 两者必须同时设置 |
| Domain 写成顶层域名 | 所有子域共享，任一子域被攻破即失守 | 限定到实际需要的最小子域 |
| 过期时间过长 | 凭证泄露后有效窗口大 | 会话 Cookie 用会话级，持久化设合理上限 |
相关产品与指南
常见问题
SameSite 不写会怎样？▼
现代浏览器默认按 Lax 处理，跨站 POST 请求不携带 Cookie，一定程度上能防 CSRF。但依赖默认值不可靠，老版本浏览器行为和默认值不同，显式声明才能保证各端一致。
设了 SameSite=Strict 为什么登录态丢了？▼
Strict 最严格，从外部链接点进站点的第一次请求不携带 Cookie，用户会看到未登录状态，需要刷新或二次跳转才恢复。多数业务用 Lax 更合适，只有高敏感操作页面才考虑 Strict。
HttpOnly 会不会影响前端读取？▼
会。加了 HttpOnly 后 document.cookie 读不到这个 Cookie，前端需要改用接口返回用户信息。这是设计意图，会话凭证本来就不应该暴露给脚本。
为什么 SameSite=None 的 Cookie 没生效？▼
SameSite=None 必须同时带 Secure，否则浏览器直接丢弃。另外部分浏览器对第三方 Cookie 有额外限制，需要在隐私沙盒策略下单独验证。
会话 Cookie 该设多长有效期？▼
管理后台这类敏感系统建议用会话级 Cookie，关浏览器即失效。面向用户的普通站点可以设 7 到 30 天，但要配合服务端会话吊销机制，改密码或异常登录时能立即失效。