Cookie 属性在防什么
会话 Cookie 的属性决定了它被谁、在哪、以什么方式发送：缺少 HttpOnly 时脚本可以读取，一次跨站脚本就能带走会话；缺少 Secure 时明文流量里可能带上它；SameSite 未设置或设为 None 时，跨站请求会自动携带凭据。核查要逐域名进行，并覆盖子域与遗留系统——同一套业务的主站修好了，老后台的 Cookie 属性往往还是老样子。
基本信息
| 核心属性 | Secure、HttpOnly、SameSite、Max-Age、Path、Domain |
|---|---|
| 前缀保护 | __Host- 强制 Secure 且不带 Domain；__Secure- 仅要求 Secure |
| 核查方式 | 登录后导出 Cookie 清单，逐条记录属性 |
| 覆盖范围 | 主域、子域、API 域、遗留系统与第三方集成场景 |
| 例外处理 | 确需前端读取的 Cookie 单独评估必要性并说明理由 |
典型使用场景
- 登录与会话机制评审的基础项
- 跨站脚本类问题的风险放大评估：会话是否能被脚本读取
- 子域扩张后复核：新建子域的 Cookie 属性是否合规
- 排查「同一浏览器下不同系统的会话互相影响」这类问题
- 修复验证：确认新属性已在所有入口生效且未破坏业务
核查方式
核查方式
curl -sI https://example.com/login # 观察响应头中的 Set-Cookie 属性
curl -sI https://api.example.com/login # 逐域核对，不要只看主站
# 记录：Cookie 名 + Secure/HttpOnly/SameSite/Domain/Path + 生效范围
# 浏览器侧：DevTools 的 Application 面板可导出完整 Cookie 清单
# 特别注意 Domain 被设成父域的场景：会话会随所有子域请求发送属性与风险
| 属性 | 缺失时的风险 | 建议 |
|---|---|---|
| HttpOnly | 脚本可读取会话，跨站脚本直接导致会话失窃 | 会话 Cookie 一律加上 |
| Secure | 明文流量可能携带会话 | 全站 HTTPS 后强制加上 |
| SameSite | 跨站请求自动携带凭据，扩大 CSRF 面 | 默认 Lax，跨站必需场景单独评审 |
| Domain 过宽 | 会话被发送到全部子域，任一子域被攻陷即受影响 | 能不用 Domain 就不用 |
修复视角：会话 Cookie 默认 Secure + HttpOnly + SameSite=Lax；需要跨站携带的场景单独评审，而不是全站放开。
__Host- 前缀是一道额外的保护：它强制浏览器要求 Secure 且不允许设置 Domain，可以防止会话被意外扩散到子域。