简介：这套名为 cookie-stealer 的 JS 小工具，定位为前端安全与浏览器 Cookie 机制的学习演示，适合具备基础脚本知识、希望理解 Cookie 读取流程、调试方式与风险边界的学生和开发者参考。压缩包共 7 个文件，约 33KB，包含 3 个 js 脚本、1 个 json 配置、1 个 html 页面，以及 md 说明和 py 服务端脚本，体量轻便，便于本地阅读、拆解与对照实验。已有 186 人学习，说明其在相关入门练习中具有一定参考价值。读者可从中观察页面脚本、扩展配置与简易服务端之间的协作关系，结合说明文档梳理 Cookie 存取链路、调试思路与常见防护策略，并进一步理解同源策略、Cookie 属性及前端安全边界。目录结构简洁，适合作为课堂演示、课程作业或安全认知练习的辅助材料，也便于在受控环境中开展代码阅读与风险分析。
1. 先看清它偷的是什么：一个演示型 Cookie 读取工具的定位
前阵子有人往群里丢了一个压缩包，解压出来就一个 JavaScript 文件，名字直白得吓人——cookie-stealer。打开一看，不到一百行，核心就是读document.cookie、拼字符串、再想办法把结果送出去。很多人第一反应是“这也能叫项目”，但它恰恰是个很好的反面教材：它把浏览器里最容易被误解的一块能力——同源脚本对 Cookie 的可见性——赤裸裸摊在你面前。真正值得花时间的不是照着它去拿别人的登录态，而是借这份源码看清自己站点上哪些 Cookie 正在裸奔、哪些已经挂上了 HttpOnly。前端的 JavaScript 代码写多了，你会越来越在意这种边界问题，而不是相反。
2. 原理拆解：document.cookie 的可见边界与一次完整读取链路
这个工具之所以“简单”，是因为它依赖的浏览器 API 本身就极其朴素。document.cookie从诞生起就不是一个操作系统级的安全接口，它是一个同源脚本可读写的名字值文本串。理解它的边界，比单纯看懂那几十行拼接字符串的代码重要一百倍。
2.1 document.cookie 到底能读到什么
先把最关键的一句话摆出来：在当前页面上执行的 JavaScript，只能看到属于当前域、未设置 HttpOnly、且未过期的那部分 Cookie。其余的一律看不到，也写不了。这三点任一不满足，document.cookie里就是空的，不是“读到了空字符串”，而是根本没有那一条。
一个真实的 Cookie 在浏览器里长这样：
Set-Cookie: session_id=abc123; Path=/; Domain=example.test; Expires=Wed, 09 Jun 2027 10:18:14 GMT; Secure; HttpOnly; SameSite=Lax这里面session_id=abc123是名字和值，后面全是属性。属性和“值”在存储层是分开的，但document.cookie这个 API 只返回名字=值这一截，属性一律不返回。这是很多新手第一次踩的坑：以为能从document.cookie里读出HttpOnly，读不出来，因为带HttpOnly的那条压根不会出现在里面。
写一段自查代码，把当前页面能看到的 Cookie 全部结构化出来：
// 仅用于在自己站点上做自查：列出"当前页面脚本可见"的 Cookie function listVisibleCookies() { // document.cookie 返回形如 "a=1; b=2" 的字符串，; + 空格 分隔 return document.cookie .split(';') .map(item => item.trim()) .filter(Boolean) .map(item => { // 只按第一个 = 切分，值里含 = 的情况（如 base64）才不会被截断 const idx = item.indexOf('='); const name = idx > -1 ? item.slice(0, idx) : item; const value = idx > -1 ? item.slice(idx + 1) : ''; return { name, length: value.length, // 只取长度，避免把敏感值打印到控制台 hasValue: value.length > 0 }; }); } console.table(listVisibleCookies());这段代码的三个处理点值得说明。split(';')之后必须trim()，因为浏览器输出的分隔符是分号加空格，不 trim 会导致名字前面带空格，匹配失败。indexOf('=')而不是split('=')，是因为 JWT、base64 编码的值里经常出现等号，直接 split 会把值截断。最后只输出length不输出value，是有意为之——自查脚本跑在真实环境里时，把明文会话值打到控制台，等于给自己制造二次泄露面，血泪经验。
跑完你会得到一张表。凡是出现在这张表里的，都是“脚本可读”的，也意味着一旦有 XSS，它们就等同于已经泄露。这正是那个 cookie-stealer 存在的全部前提。
2.2 从读取到外发：这类工具的最小链路长什么样
理解了可见性，那个工具的剩下部分就没什么神秘的了。它的链路永远是三段：读取 → 序列化 → 外发。
第一段就是上一节的document.cookie。第二段通常是拼成?data=查询串或者 JSON body。第三段是new Image().src = ...、fetch(...)、navigator.sendBeacon(...)中的一种。老一点的用 Image 打点，因为不受跨域限制、不触发预检；新的更倾向sendBeacon，因为页面卸载时也能发出去。
注意：这一段我不给可执行的完整外发代码。不是因为写不出来，而是这类代码离开“自己的测试域名”这个前提，就没有任何正当用途。原理层面看懂链路就够了。
真正需要你记住的是：这条链路的每一环都受浏览器约束。
- 读取环受 HttpOnly 约束，带这个属性的 Cookie 直接消失。
- 序列化环受字符长度约束，Cookie 总量一般有 4KB 上下的单域限制，超出的部分浏览器直接丢。
- 外发环受 CSP 的
connect-src、img-src约束，也受 SameSite 影响——如果目标接口靠 Cookie 认证，跨站请求默认不带 Cookie。
所以一个站点只要把 HttpOnly、CSP、SameSite 三件事做到位，这个工具在它面前就是一堆废代码。反过来，如果你在自己的项目里跑一遍它的思路，发现能读出session_id，那就是实打实的漏洞，得立刻改。
2.3 为什么 HttpOnly 是那道真正的闸门
把所有属性排个序，HttpOnly 的优先级最高，因为它直接作用于“脚本能不能看见”这件事，而不是“请求带不带”。后者是 SameSite 和 CSRF 令牌的事，前者是 XSS 泄漏面的事，两个维度。
HttpOnly 的实现机制在浏览器内核里，脚本层没有任何 API 能绕过它。有人会想“那我用XMLHttpRequest请求自己的页面，再解析响应头不就行了”——不行，Set-Cookie是禁止被脚本读取的响应头之一，getResponseHeader('Set-Cookie')永远返回 null。还有人想读document.cookie的“完整版”，也没有这种接口。
这也是为什么很多团队的做法是：会话票据一律 HttpOnly，前端只留非敏感的展示型 Cookie。比如theme=dark、lang=zh-CN、last_visit=...，这些被偷了也无所谓；session_id、refresh_token、csrf_token的全部或部分必须走服务端设置 + HttpOnly。
有个细节容易被忽略：csrf_token有时反而需要被前端 JavaScript 读取（用于放进请求头做双提交校验），这时它不能设 HttpOnly。解决方式是拆成两个：一个 HttpOnly 的会话 Cookie，一个非 HttpOnly 的 CSRF Cookie，服务端校验两者是否配对。这是常见做法，也是我在实际项目里会优先选的路子。
3. 隔离环境搭建：把这类演示项目跑在可控沙箱里
知道了原理，接下来要能动手验证。验证的前提是隔离：绝不能拿任何真实站点的 Cookie 去试。我一般会在本机起一个只监听 127.0.0.1 的测试服务，用假域名和假数据把整条链路跑通，然后再决定要不要在自己的真实项目上做同样的检查。
3.1 目录结构与运行方式
这类演示项目结构极简，通常就是这样：
cookie-demo/ ├── public/ │ ├── index.html # 演示页面，引入下面的脚本 │ └── probe.js # 读取并展示可见 Cookie 的脚本 ├── server.js # 本地测试服务，负责下发各种属性的 Cookie └── package.jsonserver.js用原生http模块就够，不引框架，减少变量。关键是它要能同时下发四种 Cookie：普通、HttpOnly、Secure、SameSite 各一种，方便对照观察。
// server.js —— 本地测试服务，只监听回环地址 const http = require('http'); const fs = require('fs'); const path = require('path'); const server = http.createServer((req, res) => { if (req.url === '/') { // 一次下发四条属性不同的 Cookie，用于对照实验 res.setHeader('Set-Cookie', [ // 1. 普通 Cookie：脚本可读 'plain_demo=hello; Path=/; Max-Age=3600; SameSite=Lax', // 2. HttpOnly：脚本读不到，这是对照组的关键 'session_demo=fake-session-value; Path=/; Max-Age=3600; HttpOnly; SameSite=Lax', // 3. SameSite=Strict：跨站请求不带 'strict_demo=s; Path=/; Max-Age=3600; SameSite=Strict', // 4. 带 Secure：仅 https 下生效，本地 http 环境会被丢弃 'secure_demo=x; Path=/; Max-Age=3600; Secure; SameSite=Lax' ]); const html = fs.readFileSync(path.join(__dirname, 'public/index.html')); res.setHeader('Content-Type', 'text/html; charset=utf-8'); return res.end(html); } res.statusCode = 404; res.end('not found'); }); server.listen(3000, '127.0.0.1', () => { console.log('http://127.0.0.1:3000'); });启动方式就一句：
node server.js然后浏览器打开http://127.0.0.1:3000。这里有几个参数需要说清楚。
Max-Age=3600是相对过期时间（秒），比Expires更可靠，因为它不受客户端时钟偏差影响。Path=/决定这条 Cookie 在哪些路径下会被发送和可见，写成/admin就只在/admin下出现——这一点在排查“为什么这个页面读不到 Cookie”时极其关键。
Secure那条在本地http://环境下会被浏览器直接丢弃，你在 DevTools 里根本看不到它。这不是代码写错了，是设计如此。想在本地验证 Secure 属性，要么配置本地 https，要么接受“生产环境才有”这个事实。我第一次碰到时对着屏幕找了半小时，以为是浏览器版本问题，实际上是规范行为。
3.2 用可控测试站点造出“可被读取”的 Cookie
上面那个服务起来之后，把probe.js挂进index.html：
<!doctype html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <title>Cookie 可见性演示</title> </head> <body> <h1>当前页面脚本可见的 Cookie</h1> <pre id="out"></pre> <script src="./probe.js"></script> </body> </html>probe.js就是第 2 章那段listVisibleCookies，把它输出到页面上而不是控制台，方便截图存档。跑起来之后你应该看到：plain_demo和strict_demo出现在列表里，session_demo不出现，secure_demo在 http 下也不出现。
这个对照实验做一遍，HttpOnly 的作用就不再是文档上的一句话，而是你亲眼看到的“少了那一行”。
再补一个写入实验，验证脚本能写什么：
// 脚本写入的 Cookie，无法指定 HttpOnly // 写 HttpOnly 不会报错，但属性会被浏览器静默忽略 document.cookie = 'written_by_js=1; Path=/; Max-Age=600; SameSite=Lax'; document.cookie = 'try_httponly=1; Path=/; Max-Age=600; HttpOnly';第二行值得单独说：HttpOnly是只能由服务端设置的属性，脚本里写它不会抛异常，但浏览器会忽略这个属性，结果就是一条普通 Cookie。这个静默失败特别容易让人误判“我明明设了 HttpOnly 怎么还能读到”，因为前端代码里写的那一行等于没写。
3.3 DevTools 里的观察点
浏览器开发者工具是两个面板配合看。
Application → Storage → Cookies：这里能看到该域下所有 Cookie，包括 HttpOnly 的那条。注意，DevTools 能看到不代表脚本能看到，这个面板是浏览器提供的“管理视图”，不属于页面脚本的运行环境。很多新手在这里看到session_demo存在，就以为脚本也能读，然后困惑半天。
那个列的表面有一个HttpOnly勾选列，一条竖线打勾就是已设置。这是最快的核对方式。
Network → 某个请求 → Request Headers：看实际发出去的Cookie:头。这个才是服务端真正收到的东西，它包含 HttpOnly 的条目，因为 HttpOnly 只限制脚本读取，不限制请求携带。这个区别要牢记：HttpOnly 防的是“被读走”，不是“被发出”。
再配合 Console 跑一次document.cookie，三个视角一对照，任何“为什么读不到”的疑惑基本都能定位。
4. 服务端加固实操：Set-Cookie 的三个关键属性
实验做完，回到真实项目。Cookie 的安全属性只有服务端能设，所以加固的落点全在后端。这一章给的是可以直接抄的配置和取舍逻辑。
4.1 HttpOnly 与 Secure 的配置写法
不同技术栈写法不同，但本质都是往响应头里拼属性。Node 生态里如果用了 express，最常见的做法是res.cookie()：
// express 中下发会话 Cookie 的典型写法 app.post('/login', (req, res) => { // ...校验账号密码，生成会话票据 res.cookie('session_id', ticket, { httpOnly: true, // 脚本不可读，必须开 secure: process.env.NODE_ENV === 'production', // 生产走 https，本地开发关掉 sameSite: 'lax', // 见下一节 path: '/', maxAge: 1000 * 60 * 60 * 2 // 2 小时，单位毫秒 }); res.json({ ok: true }); });secure这里用了环境判断，是因为本地开发一般是 http，硬开secure: true会导致 Cookie 根本不下发，登录状态永远保持不住。这个坑几乎每个项目都会踩一次，表现是“本地登录成功但刷新就掉登录”，查半天以为是 session 存储问题。
maxAge单位是毫秒（express 内部会转成秒），和原生Set-Cookie的Max-Age秒不是一回事，混用会导致会话时长差 1000 倍。
如果没用框架，手拼响应头也行：
res.setHeader('Set-Cookie', [ `session_id=${ticket}; Path=/; Max-Age=7200; HttpOnly; Secure; SameSite=Lax` ]);手拼时要注意值里不能有分号、逗号、空格，票据如果是 base64 要确认字符集安全，必要时用encodeURIComponent。
4.2 SameSite 的取值与业务取舍
SameSite管的是“跨站请求要不要带这条 Cookie”，它防的是 CSRF 那一类问题，和 HttpOnly 防的不是一回事。三个取值：
| 取值 | 跨站请求是否携带 | 典型适用场景 | 代价 |
|---|---|---|---|
Strict | 完全不携带 | 后台管理、支付确认等强敏感操作 | 从外部链接点进来时首次请求不带登录态，表现为“点链接进来要重新登录” |
Lax | 顶层导航的 GET 携带，其余不带 | 绝大多数业务站点的默认选择 | 少数需要跨站 POST 的场景会失效 |
None | 一律携带 | 必须跨站携带的嵌入场景（iframe、第三方回调） | 必须同时设Secure，否则浏览器直接拒绝 |
我的默认选择是Lax。它在安全性和可用性之间的平衡最好，也是主流浏览器的默认值。只有明确需要跨站携带时才降级到None，而且要清楚这意味着 CSRF 防护要完全靠令牌来做。
有个具体的翻车场景值得说：某次做一个第三方页面嵌入的需求，会话 Cookie 设的是Lax，结果 iframe 里所有接口都 401。原因是 iframe 里的请求属于跨站请求，Lax一律不携带。改成None; Secure之后立刻正常，但同时也意味着必须补齐 CSRF 令牌校验，否则等于把门敞开。这类取舍要在需求评审阶段就提出来，别等到联调才发现。
4.3 CSP 与 XSS 面的收口
前面所有属性防的都是“读走之后怎么用”，而源头是 XSS——没有脚本注入，就没有document.cookie被读的机会。所以真正的收口在 CSP。
一个偏严格的策略大概长这样：
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-随机值'; connect-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'逐条说清楚作用。script-src 'self'禁止内联脚本和外部域脚本，这一条直接把绝大多数注入型 XSS 掐死；配合nonce-可以给确需内联的脚本开口子，每次请求生成新随机值。connect-src 'self'限制fetch/XHR只能发往同源，等于把“外发”这一环也堵了——这一点常被忽略，其实它对 cookie-stealer 这类链路是致命的。img-src限制图片源，因为老式外发用new Image().src。object-src 'none'关掉插件类入口。
上线 CSP 的正确姿势是先上Content-Security-Policy-Report-Only，收集一段时间违规报告，把误报的域补进白名单，再切成强制模式。直接上强制模式，大概率当天就把某个统计脚本或字体服务打挂。
5. 排查：Cookie 读不到、写不进、带不上的常见问题
这类问题排查起来最耗时间，因为浏览器的表现往往是“静默失败”，没有报错。下面几条是我实际遇到过、并且能复现的。
现象一：document.cookie返回空字符串，但 DevTools 里明明有 Cookie。原因基本是全部条目都带了 HttpOnly，或者只在其他 Path 下可见。前者说明配置是对的，不用管；后者是路径不匹配。解决方式是到 Application 面板逐条看 Path 列，确认当前页面路径是否在 Cookie 的 Path 覆盖范围内。同名 Cookie 在不同 Path 下可以并存，这个特性经常造成“我改了配置怎么没生效”的错觉。
现象二：本地开发登录成功，刷新页面就掉登录。原因是secure: true在 http 环境下导致浏览器丢弃 Cookie。解决方式是按环境变量切换，生产开、本地关；或者本地配 https。要注意这个现象和“session 存内存重启丢失”表现很像，先看 Application 面板有没有那条 Cookie，有就是别的问题，没有就是 Secure 拦的。
现象三：跨域接口请求不带 Cookie，服务端拿不到登录态。原因是fetch默认credentials: 'same-origin'，跨域时不带凭据。解决方式是前端显式设credentials: 'include'，同时服务端 CORS 必须返回Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin不能是*，必须是具体源。这两个条件缺一个都不行，且浏览器控制台只会给一句含糊的 CORS 报错，很容易往错误方向查。
现象四：脚本里写了HttpOnly却没生效，仍然能读到。原因在 3.2 节说过，HttpOnly 只能由服务端设置，脚本里写是被静默忽略的。解决办法是把设置动作全部挪到服务端，前端一行都别写。这也是我坚持“会话类 Cookie 一律服务端下发”的原因。
现象五：Cookie 值里出现%或者被截断。原因是值里含有分号、逗号、空格、非 ASCII 字符，浏览器解析时按分隔符截断了。解决方式是在服务端设置前做encodeURIComponent，前端读取后decodeURIComponent。中文用户名、带空格的 JSON 串都是高发对象。
6. 把它改造成自查工具：一次合规的 Cookie 属性审计
到这一步，那个 cookie-stealer 的价值就彻底变了——它不再是“怎么偷”的样本，而是提醒你该做一次 Cookie 属性审计。我后来把它的读取逻辑整个反转，做成一个只读、不外发、只在自己域名下运行的自查脚本，挂在测试环境里定期跑。
核心思路是：只判断属性是否缺失，绝不记录值。浏览器脚本读不到 HttpOnly 的条目，这反而是个天然的判据——预期应该有 HttpOnly 的会话 Cookie，如果出现在可见列表里，就说明配置漏了。
// 站点自查：核对关键 Cookie 是否出现在"脚本可见"范围内 // 出现在这里 = 没设 HttpOnly = 需要修 const SHOULD_BE_HTTPONLY = ['session_id', 'refresh_token', 'auth']; function auditCookieHttpOnly() { const visible = new Set( document.cookie.split(';').map(s => s.trim().split('=')[0]).filter(Boolean) ); const leaked = SHOULD_BE_HTTPONLY.filter(name => visible.has(name)); if (leaked.length > 0) { // 只上报名字，不上报值，避免自查脚本本身变成泄露源 console.warn('[Cookie 审计] 以下 Cookie 未设置 HttpOnly：', leaked); // 可上报到内部监控，注意上报接口本身要鉴权 // navigator.sendBeacon('/internal/audit', JSON.stringify({ leaked })); } else { console.info('[Cookie 审计] 关键 Cookie 均不可被脚本读取'); } } auditCookieHttpOnly();这段代码里最容易做错的一步是上报。sendBeacon那行我特意注释掉了，因为很多团队一激动就把leaked连同上下文一起上报，结果审计系统本身成了新的数据汇聚点。正确做法是只报“哪些名字缺失”，值是绝对不进日志的。
再往下可以做两件事。一是把这份检查接到 E2E 测试里，每次发布前跑一遍，属性回退能第一时间发现——这比事后排查便宜太多。二是配合服务端做一次全量盘点，把所有Set-Cookie的点位列出来，逐条标上是否 HttpOnly、SameSite 取值、有效期，做成一张表挂在文档里。我做过的项目里，凡是没做过这张表的，半年内必然出现一次“新同事加了个 Cookie 忘了加属性”的事故。
验证方法也很直接：改完配置后，回到第 3 章的本地环境，把四条对照 Cookie 再跑一遍，确认session_demo依然不出现在document.cookie里，同时 Network 面板里请求头依然带着它。两个条件同时满足，才算改对了。
说个我自己踩过的教训。早年接手一个老项目，会话 Cookie 一直没设 HttpOnly，理由是“前端有个地方要读用户 ID”。我去看了一眼，那个地方读的是一个叫uid的展示用 Cookie，跟会话票据八竿子打不着，纯粹是当年图省事把两件事塞进了同一条 Cookie。拆开之后前端一行没改，安全性直接上了一个台阶。从那以后我每次评审登录相关代码，都会强制走一遍“这条 Cookie 到底谁在读”的确认流程，问清楚读它的是服务端还是脚本、读来干什么、能不能换成别的载体。这份 cookie-stealer 的源码我留在了本地一个叫security-samples的目录里，不是为了运行，是为了在下次有人问“Cookie 被偷了会怎样”的时候，直接打开那个对照实验页面给他看。希望帮到你。
本文还有配套的精品资源，点击获取
