速查在线工具箱Cookie 属性与安全标志速查
HttpOnly、Secure、SameSite 各自挡住哪类攻击、Domain 与 Path 的匹配规则、会话 Cookie 与持久 Cookie 的差别。
Cookie 是服务器让浏览器「记住一点东西」的机制：登录状态、偏好设置、购物车都靠它。它默认会把内容随每次请求带回服务器，因此既是功能的基础，也是安全上最需要小心处理的部分。
问题的核心在于：如果 Cookie 被恶意脚本读到，就等于登录凭证被偷走。所以现代 Cookie 有一套明确的安全标志——HttpOnly 挡住脚本读取，Secure 保证只走加密通道，SameSite 限制跨站携带。理解这三个，就掌握了 Cookie 安全的主要部分。
1常用属性对照
一个 Cookie 由「名字=值」加若干属性组成。属性写在 Set-Cookie 响应头里，用分号分隔，浏览器按属性决定这个 Cookie 的可见范围与生命周期。
| 属性 | 作用 | 取值与效果 |
|---|---|---|
HttpOnly | 禁止 JavaScript 读取 | 布尔标志。设了之后 document.cookie 读不到，可挡 XSS 窃取 |
Secure | 只在加密连接中发送 | 布尔标志。仅 https 请求会带上，可挡明文嗅探 |
SameSite | 限制跨站请求是否携带 | Strict / Lax / None 三档，见下一节 |
Domain | 指定可接收该 Cookie 的主机范围 | 不设时仅当前主机（不含子域）；设为 .example.com 则含所有子域 |
Path | 指定生效的路径前缀 | 如 Path=/admin，只有该路径下的请求才带 |
Max-Age | 有效秒数 | Max-Age=3600 表示一小时后失效，优先级高于 Expires |
Expires | 过期时间点 | 绝对时间；不设 Max-Age 也不设它则为会话 Cookie |
Partitioned | 分区存储（较新的属性） | 把 Cookie 按顶级站点隔离，缓解跨站追踪 |
会话 Cookie（不设 `Max-Age` 与 `Expires`）在浏览器关闭后通常会被清除，适合放登录态；持久 Cookie 有明确过期时间，适合放「记住我」这类偏好。但要注意「关闭浏览器」的定义在移动端并不一致，重要状态不要只依赖会话 Cookie 的生命周期。
2SameSite 三档怎么选
SameSite 控制「从别的站点发起的请求要不要带上这个 Cookie」，是防御 CSRF 的关键开关。三档的宽松程度递增。
| 取值 | 跨站请求是否携带 | 适用场景 | 代价 |
|---|---|---|---|
Strict | 完全不携带 | 银行、后台管理等安全优先的场景 | 从外部链接点进来时首次请求不带 Cookie，可能显示为未登录 |
Lax | 顶层导航的 GET 会带，其余不带 | 默认推荐值，兼顾安全与体验 | 跨站的表单 POST 不带 Cookie，可能影响部分回调流程 |
None | 总是携带 | 确实需要跨站携带的场景，如内嵌登录 | 必须同时设 Secure，否则浏览器会拒绝 |
| 默认行为 | 未显式设置时，现代浏览器按 Lax 处理 | — | 依赖默认值不如显式写清楚，便于审计 |
| CSRF 关系 | Strict 与 Lax 都能挡掉大部分 CSRF | 表单类跨站伪造提交被拦下 | 真正敏感的操作还应配合 CSRF Token |
SameSite 是「降低风险」而不是「消除风险」。真正涉及资金、权限变更的操作，仍应使用 CSRF Token 或要求二次验证。把 CSRF 防护完全寄托在一个 Cookie 属性上并不稳妥。
3Domain 与 Path 的匹配规则
这两个属性决定「哪些请求会带上这个 Cookie」。它们的匹配方式是「后缀匹配」，理解这一点可以避免作用域设得过宽。
| 设置 | 生效范围 | 要点 |
|---|---|---|
不设 Domain | 仅当前主机（如 www.a.com） | 子域（api.a.com）不会带上 |
Domain=a.com | a.com 及其所有子域 | 写作 .a.com 效果相同，前导点可省略 |
Domain=api.a.com | 仅 api.a.com | 注意不能设为 sub.www.a.com 这种非自身后缀 |
Path=/ | 整个站点都携带 | 最宽松，多数场景的默认选择 |
Path=/admin | /admin 及其子路径 | /administrator 也会匹配，因为是前缀匹配 |
| 作用域过宽的后果 | 子域之间互相可见 | 若某个子域被入侵，可读到主域 Cookie，应尽量收窄 |
把登录 Cookie 的 `Domain` 设成顶级域名（如 `.a.com`）会让所有子域都能读到它，包括自建的博客子域、测试子域。除非确有必要，否则不要主动放宽 `Domain`——保持默认的「仅当前主机」是最安全的。
4推荐的 Cookie 配置组合
不同类型 Cookie 的安全要求不同。以下是一组在实践中广泛采用的组合。
- 登录态 Cookie
HttpOnly; Secure; SameSite=Lax; Path=/，并设置合理有效期。不放任何脚本需要读的信息- 需要 JS 读取的偏好项
- 可以不加
HttpOnly，但依然要加Secure; SameSite=Lax，且不要放敏感内容 - 跨站必需场景
- 设
SameSite=None; Secure，并把Domain收到最小范围，同时配合 CSRF Token - 内容安全策略配合
- 即使有
HttpOnly，也应配置 CSP 减少 XSS 面，HttpOnly只是最后一道防线 - 前缀加固
- 使用
__Host-前缀的 Cookie 会被浏览器强制要求Secure、Path=/且不带Domain，能进一步防止子域写入 - 审计方式
- 在开发者工具的 Application 面板逐个检查属性，或用响应头分析工具确认服务端确实下发了这些标志
5三类常见故障的成因
- 登录后刷新就掉登录
- 多为 Cookie 被设成了会话级，或路径 / 域不匹配导致后续请求没带上。核对
Path、Domain与请求地址是否吻合 - 本地开发正常，上线后 Cookie 丢了
- 本地是
http而线上是https，或反了：设了Secure的 Cookie 在http页面下不会被保存 - 跨站回调后未登录
SameSite设得较严（Strict）或未设None，导致从第三方跳回时 Cookie 未被携带- Cookie 数量或体积超限
- 单域名下 Cookie 的数量与总大小都有浏览器上限，放太多数据会被丢弃。大数据应存服务端，Cookie 只存一个标识
- 设置不生效
- 同一个 Cookie 名在相同
Domain/Path下重复设置会互相覆盖，排查时注意是否有旧配置在别处又设了一次
看完就能用的站内工具
全部工具总览 →在线生成 Set-Cookie 响应头，配置 SameSite、Secure、HttpOnly、Max-Age 与 __Host- 前缀，并自动校验属性冲突
在线生成网站安全响应头配置，包含 HSTS、X-Frame-Options、X-Content-Type-Options、Referrer-Policy 等，输出 Nginx 与 Apache 配置片段
在线解析 HTTP 响应头，逐项检查 HSTS、CSP、X-Frame-Options 等八项安全头是否齐全，同时提示 Server、X-Powered-By 等信息泄露头与缓存策略配置，并给出安全评分，粘贴响应头即可出结果。
关于「Cookie 属性与安全标志速查」的常见问题
HttpOnly 和 Secure 有什么区别？
两者防的是完全不同的攻击。HttpOnly 禁止 JavaScript 通过 document.cookie 读取该 Cookie，目的是即使页面被注入恶意脚本（XSS），脚本也偷不走登录凭证；Secure 则要求 Cookie 只在 HTTPS 加密连接中传输，目的是防止通过网络明文嗅探截获。所以它们不能互相替代，登录态 Cookie 应该同时设置这两个标志。补充一点：HttpOnly 只是降低了 XSS 得手后的损害，并不能阻止 XSS 本身，真正减少 XSS 要靠输入输出转义和内容安全策略。
SameSite 的 Strict、Lax、None 该怎么选？
按「安全优先还是体验优先」来权衡。Strict 最安全，跨站场景完全不携带 Cookie，但代价是用户从外部链接点进来时首次请求会显示为未登录（需要再点一次或刷新）；Lax 是当前的默认值，允许顶层导航的 GET 请求携带 Cookie，挡住了绝大多数 CSRF 攻击又不太影响体验，适合大多数网站；None 表示总是携带，只在确实需要跨站携带时才用，而且必须同时设置 Secure，否则浏览器会直接拒收。涉及敏感操作时，无论选哪档都建议再加 CSRF Token。
Cookie 的 Domain 设成 .example.com 有什么风险？
风险在于作用域被放大了。设成 .example.com 后，www、api、blog、test 等所有子域都能读取到这个 Cookie，而子域往往是安全防护相对薄弱的部分——一个测试子域、一个第三方托管的博客子域被攻破，攻击者就能读取主站的登录 Cookie。所以除非确实需要在多个子域之间共享登录态（单点登录场景），否则应保持默认设置（不指定 Domain，只对当前主机生效）。需要跨子域共享时，也应尽量收窄到必要的范围，并考虑使用 __Host- 前缀来强制更严格的约束。
为什么设了 Secure 之后本地开发环境 Cookie 就没了？
因为 Secure 属性规定该 Cookie 只在 HTTPS 连接中发送和保存，而本地开发常用 http://localhost 访问，浏览器不会保存或发送带 Secure 的 Cookie，表现就是「登录不上」。常见的处理办法是：本地开发时不加 Secure，通过环境配置区分；或者本地也启用 HTTPS（用自签证书或本地证书工具）；再或者使用 .localhost 这类浏览器特例域名。关键是不要把「本地关掉 Secure」的配置带到生产环境，最好用配置项明确区分而不是手工改代码。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。