Set-Cookie: sid=opaque…; Path=/; Max-Age=1800; SameSite=Lax; Secure; HttpOnly浏览器自动在符合范围的同站 HTTPS 请求里带上 sid，脚本读不到；服务端按 sid 查会话。日志、历史、Referer 都拿不到完整凭据。
数据与服务 · 网络与接口
浏览器 CookieCookie
Cookie 是浏览器管理的请求状态，适合短期会话标识和非敏感偏好；它不替代 Authorization token、CSRF 校验或服务端权限检查，也不能装明文秘密。
配置 sid Cookie，判定哪些请求会被自动带上
Cookie 不是服务器塞进去就一定生效：浏览器每次请求前都会按主机、路径、连接和跨站四道门重新筛选。先在这一台改属性、判请求，再读后面的规则命名。
服务器登录成功后设了一条 sid Cookie（Domain 固定为 app.example.com）。 配好下面的属性，再点主操作「判定这批请求」，看 6 条探针各自被带上、不带还是可读 / 读不到。
当前响应 · Set-Cookie
Set-Cookie: sid=opaque…; Domain=app.example.com; Path=/account; Max-Age=1800; SameSite=Lax; Secure; HttpOnlySecure
SameSite
Path
HttpOnly
未判定：配置好属性后点「判定这批请求」揭晓结果。
- 请求
GET https://app.example.com/account同站 · HTTPS待判定 - 请求
GET https://app.example.com/dashboard同站 · HTTPS待判定 - 请求
GET http://app.example.com/account同站 · 明文 HTTP待判定 - 请求
GET https://shop.example.com/account另一台主机待判定 - 请求
POST https://app.example.com/account跨站表单 · 来自 evil.example待判定 - 脚本
READ document.cookie页面脚本读取 sid待判定
下一步：配好 Secure / SameSite / Path / HttpOnly 后点「判定这批请求」，6 条探针各自亮出带上、不带或可读。 原因与对照会在判定后出现；改任意属性会先清空旧结论——先预测，再判定。
提示：属性分段按钮用 Tab 聚焦、Enter 选择；重点试三组对照——Secure on/off、SameSite 三档、Path /account 与 /。
判定台暴露的四道门加一条脚本线
面板已经把每条规则演给你看了，这里把它们命名清楚，并补上无法直接操作的部分。
- Set-Cookie 是报名，属性是挂号：服务器用
Set-Cookie: sid=…; 属性提出保存请求；浏览器接到后先保存，再等每次请求的筛选。Max-Age/Expires决定它活多久。 - Domain / 主机门：未设 Domain 时是 host-only，只回到设置它的那台主机；即便设了
Domain=example.com，也只覆盖子域，不跨到无关域名。 - Path 门：按路径前缀匹配，
Path=/account不覆盖/dashboard；它是范围不是权限，敏感操作仍要服务端授权。 - Secure 门：只在 HTTPS 连接发送；生产会话必须配，否则明文 HTTP 上一并泄漏。
- SameSite 门：
Strict任何跨站都不带；Lax（默认）只在顶层安全 GET 跳转带；None允许跨站，但必须同时Secure，否则浏览器直接拒绝保存。 - HttpOnly 是脚本线，不是携带线：它只挡
document.cookie读取，不阻止浏览器在符合条件时自动带 Cookie 发请求——所以它不能替代 CSRF 防护。 - 删除要原样同名：用相同的 name、Domain、Path 配
Max-Age=0才能可靠删除；服务端也要撤销会话，不能只清浏览器。
什么时候用 Cookie，什么时候换别的
从你想保存的状态和谁能读到它出发，而不是默认都用 Cookie。
- 用 Cookie：需要浏览器在后续同站请求里自动带上的状态，最典型是登录会话标识 sid 和非敏感偏好（语言、主题）。
- 换 Authorization 头（token）：调用方想显式控制凭据、跨设备使用、或走跨来源 API 时，用
Authorization: Bearer …更可控；它由代码放头，不依赖浏览器自动携带规则。 - 换 localStorage：只给本脚本用、不需要随请求自动带的状态（如 UI 开关、草稿）；它不会被浏览器自动发往服务端，但脚本完全可读，不能放会话凭据。
- 不要存的：密码、私钥、API key、完整个人资料——任何明文秘密都不该进 Cookie；用随机可撤销的 opaque sid，秘密留在服务端。
怎么设、怎么读、怎么删：最短路径
从登录到登出，只走这几步。
- 登录成功后服务端生成随机 opaque sid，落库映射到用户和角色，再回
Set-Cookie: sid=…; Path=/; Max-Age=…; SameSite=Lax; Secure; HttpOnly。 - 后续请求由浏览器自动拼
Cookie: sid=…头；服务端查 sid 对应会话与权限，不要在浏览器端读 sid 再传回来。 - 调试时在 DevTools Application / 存储 → Cookies 看每条 Cookie 的 Domain / Path / 过期和属性；接口没带登录态时先来这里。
- 登出时撤销服务端会话，并用同名、同 Domain、同 Path 的
Max-Age=0删除浏览器 Cookie；状态改动接口另留 CSRF token 或 Origin 校验。
同一份登录凭据：放 Cookie 里，还是塞进 URL
只改一处——凭据的位置——结果差很多。这是 Cookie 工程边界里最该记住的一条。
GET /api/me?token=eyJ… HTTP/1.1URL 会被网关访问日志、CDN 日志、浏览器历史、页面里的 Referer 逐一留存，还会被代理缓存键命中——凭据等于公开。改成 Cookie 或 Authorization 头即可。
快速自测
你设了 HttpOnly + Secure + SameSite=Lax 的 sid Cookie，为什么状态改动接口仍要校验 CSRF token 或 Origin？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。