互动课堂 / 浏览器卡片分发室DAILY / SECURITY TERMS

012 / Web 与应用 / Cookies

已经存进浏览器，何时才会随请求送出？

Cookie · Cookies

网站让浏览器保存了一条 Cookie。脚本可能读不到它，浏览器却仍会在合适的请求里自动带上。把“能存下”“能读到”“会发送”分成三道判断，逐一改变属性和请求情境。

开始探索 ↓9–12 分钟
动手实验 · 场景判断 · 实用检查

Cookies 概念寓意：浏览器保存并随请求发送的小型数据，常用于会话、偏好和登录状态。 — 来访者向守卫出示卡片，背包里还有不同图案的卡片，旁边有人窥探。Cookie 是浏览器保存并按规则自动附带的数据，不天然是身份凭证，也不都用于跟踪；递卡姿态不表示用户每次主动授权。

本课任务 / Cookie

追踪 Cookie 从响应设置到后续携带的全过程，说明范围、传输、脚本访问和跨站条件各自的职责。

区分 Cookie 的存储、脚本读取和请求携带
比较 Secure、HttpOnly 与显式 SameSite 的作用
验证主机范围、配置快照和到期状态

Cookie 是谁保存、谁附带的？

服务器可在响应中用 Set-Cookie 提议保存数据，浏览器按规则接受并存储，再在符合条件的后续请求中自动附带。它可用于会话、偏好等用途，不天然是身份凭证，也不是每次发送都由用户主动递交。[1][2]

三种结果为什么要分开？

保存成功，不保证脚本能读取；脚本不能读取，也不保证请求不会携带。HttpOnly 限制脚本访问 Cookie，Secure 限制发送的传输条件，SameSite 限制某些跨站情境；它们保护不同边界，不能互相替代。[2]

Cookie 属于一个完整的源吗？

Cookie 匹配涉及主机或 Domain、Path、有效期和其他属性，不按源的端口隔离。省略 Domain 的 host-only Cookie 限于设置它的主机；获准的父域范围可覆盖子域。SameSite 的“站”也不同于同源策略的“源”。[2][3]

亲手探索 / 不同条件，不同结果

浏览器做了三次判断，你看见的是哪一次？

为固定 HTTPS 教学站点设置一条符号 Cookie，再尝试脚本读取和不同请求情境。编辑属性不会直接改动已保存快照，需要重新应用；还可推进到期或删除。不会写入浏览器的真实 Cookie。

邮务员把圆形小卡放进同样标记的信封；方形和三角形卡留在各自格子里，旁边的读者没有再次递卡。

展开读图提示

读图提示

角色与机制: 邮务员比喻浏览器，分格卡盒比喻保存的 Cookie，信封比喻后续请求。形状只提示范围匹配，不是完整匹配算法。
风险在哪里: Cookie 通常由浏览器按规则自动附带，不是使用者每次亲手批准；它也不天然等同于身份凭证。图中匹配形状不能证明请求安全。
防护与边界: 携带条件包括主机或 Domain、Path、Secure、SameSite、有效期及浏览器政策。未设置 Domain 的 host-only Cookie 只匹配保存时的主机，不随发起请求的主机变化。本实验须先保存，设置草稿不会自动改写已保存快照。

在下面保存一次 Cookie，再改变请求主机：浏览器发送时读的是已保存的范围，还是尚未保存的设置草稿？

攻击机制工作台 · 封闭离线模型

存下、读到、带走，是三道不同的门。

HTTPS 商店准备设置一张符号小卡。先保存，再尝试读取和发送；修改草稿不改变已经存下的属性，拒绝新设置也不抹掉旧卡。

下一次响应的属性草稿

SameSite 草稿

主机范围草稿

Secure 草稿HttpOnly 草稿

设置主机：shop.example.test。当前范围：仅 shop.example.test（当前主机）。

已存快照：空。模拟时钟：0。

下一次请求情境

尚未检查当前条件。修改选择会清除旧结论；保留的状态可在工作台查看。

三单位寿命只是教学刻度；固定 Path=/，忽略浏览器隐私拦截、分区、重定向和端口变化。明文场景无 HTTPS 升级；Cookie 不天然是身份凭据，递卡不等于逐次授权。

玻璃挡住左侧助手直接取卡；邮务员仍能从侧槽拿卡准备装信封，右侧同事另外对照信封与登记册。

展开读图提示

读图提示

角色与机制: 透明罩比喻 HttpOnly 对脚本读取 Cookie 的限制；侧槽比喻浏览器仍可执行的发送流程；另一份登记册提示发送条件还要单独核对。
风险在哪里: HttpOnly 不阻止所有 XSS 后果，也不阻止恶意脚本利用当前会话发起操作。画面没有表示已经发送，也没有证明 HTTPS 或 SameSite 检查通过。
防护与边界: Secure 限制 Cookie 经安全连接发送，不是加密本地存储；SameSite 限制某些跨站请求携带，站与源不同，也不能替代完整 CSRF 防护。真实发送由浏览器规则决定，不由邮差肉眼比对颜色决定。

在上方分别改变 HttpOnly、Secure 与 SameSite：哪一项限制脚本读取，哪些条件影响请求携带？

随手查 / 把理解带回实际工作

理解机制之后，检查这些细节。

实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。

01 / 实用细节

先看是否被接受，再看后续行为

本例使用明确的 SameSite 属性，None 未同时设置 Secure 时拒绝保存。接受后保留当时属性的快照，界面后续修改只是下一次提案；应先核对实际保存值，再解释为什么某次请求没有带上它。[2]

02 / 实用细节

HttpOnly 阻止读值，不阻止所有利用

启用 HttpOnly 后，页面脚本不能通过普通 Cookie 接口读取该值，但浏览器仍可在符合规则的脚本发起请求中携带它。因此它不能单独消除 XSS 的全部后果，也不等于防止跨站请求伪造。[2]

03 / 实用细节

Secure 约束发送通道，不加密存储

对本例的普通站点，Secure Cookie 只在 HTTPS 请求中发送，切换到 HTTP 就会受阻。该属性不使浏览器本地保存的数据自动加密，也不证明服务器授权正确；本模型排除 localhost 等特殊处理。[2]

04 / 实用细节

把跨站方式说清楚再比较 SameSite

本例显式 Lax 允许跨站顶层安全方法 GET 导航，却不允许跨站 POST；Strict 对两种跨站例子都不携带。None 配合 Secure 可通过这里的跨站属性检查，但真实浏览器隐私策略仍可能阻止第三方 Cookie，不能保证处处发送。[2]

05 / 实用细节

范围匹配不等于权限检查

host-only 与父域范围决定是否匹配兄弟子域；Path 决定哪些请求路径可匹配，却不是可靠的授权或隔离边界。Cookie 范围不按端口分开，服务端仍需检查请求者权限，不应因某条 Cookie 被带来就无条件返回数据。[2][3]

06 / 实用细节

到期、删除和会话撤销是不同动作

到期或从浏览器删除后，这份已存 Cookie 不再被正常读取或发送。若它承载会话标识，这不等于服务端已撤销会话，也不让别处复制的标识立即失效；浏览器恢复功能还可能保留会话 Cookie，不能简单断言关窗即全部失效。[1][2][3]

从模拟，到验证

找一个获准的环境，实际检查一次。

勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。

本页已检查 0 / 5 项

接受、脚本读取和请求携带分别验证。会话用途按需要配置 Secure 与 HttpOnly。SameSite 显式选择并测试具体跨站请求方式。Domain 与 Path 范围最小化，不替代服务端授权。到期和删除已测试，会话撤销另由服务端处理。

30 秒场景小测

哪个 Cookie 属性主要限制脚本直接读取它？

能解释原因，再标记学会。

小测结果同步错题本；“已学会”沿用原有本地学习记录。

资料与依据

MDN · Using HTTP Cookies ↗
响应设置、浏览器存储与请求携带，以及会话和偏好用途
MDN · Set-Cookie Header ↗
Domain、Path、有效期、Secure、HttpOnly、SameSite 与浏览器差异
IETF RFC 6265 · HTTP State Management ↗
存储和匹配算法、有效期及不按端口隔离；2011 年文本不定义 SameSite

本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。