document.cookie无法被HTML运行环境拦截，因Cookie权限由浏览器根据协议、域名、路径及服务端响应头（如HttpOnly、Secure、SameSite）决定；关键防护是后端设置HttpOnly使敏感Cookie前端不可见，并配合网关过滤和最小化作用域。
为什么 document.cookie 无法被 HTML 运行环境“拦截”
HTML 在线运行环境（比如用户提交一段含 document.cookie 的脚本，服务端渲染执行）本身不控制 Cookie 读写权限——浏览器才是最终决策者。你写的 document.cookie 能不能读、能不能写，取决于当前页面的协议（HTTP/HTTPS）、域名、路径、以及服务端设置的 Cookie 属性（HttpOnly、Secure、SameSite），而不是运行环境加了什么“权限开关”。所谓“拦截”，其实是靠服务端响应头和浏览器策略联合生效的。
如何让运行中的 HTML 脚本读不到敏感 Cookie
关键不是在前端代码里“禁止访问”，而是确保敏感 Cookie 带 HttpOnly 标志：
-
HttpOnly必须由后端在Set-Cookie响应头中声明，例如：Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax - 前端执行
document.cookie时，所有带HttpOnly的条目**完全不会出现在返回字符串里**，不是“读不到”，是“根本看不见” - 验证是否生效：打开 DevTools → Application → Cookies → 看对应条目右侧 “HttpOnly” 列是否打钩；或直接在控制台执行
document.cookie，确认敏感字段（如sessionid）压根没出现 - 常见错误：前端试图用
document.cookie = "a=1; HttpOnly"设置，这语法无效，浏览器静默忽略
怎么阻止 HTML 运行环境写入任意 Cookie
不能靠 JS 层面“禁用写入”，而要从服务端源头控制：
- 所有 Cookie 写入必须经由后端接口（如
/api/set-cookie），且该接口需校验请求来源、用户权限、Cookie 名称白名单（例如只允许theme、lang，禁止sessionid、auth_token） - 前端运行的 HTML 不应拥有直接调用
document.cookie = ...修改关键 Cookie 的能力；若必须支持，应限制路径（path=/sandbox/）和域名（domain=.sandbox.example.com），与主站隔离 - 对用户提交的 HTML，网关层需拦截含
document.cookie=或cookie.*=的 JS 片段（通过 Nginx$request_uri或 OpenResty Lua 扫描），返回 400 —— 这是第一道过滤，但仅限明显模式，不能替代后端校验
SameSite 和 Secure 如何配合防越权写入
光靠 HttpOnly 不够，Cookie 还得防被恶意页面发起的请求带上：
立即学习“前端免费学习笔记（深入）”；
-
SameSite=Lax（推荐）可阻止大部分跨站 POST 请求携带 Cookie；SameSite=Strict更严，但可能影响正常跳转 -
Secure必须开启（生产环境），否则 HTTP 下SameSite和HttpOnly都形同虚设；注意localhost下Secure会静默失效，开发时建议用https://127.0.0.1 -
SameSite=None必须搭配Secure，否则现代浏览器拒绝设置；不要为兼容旧版而开SameSite=None却不配Secure - 如果用户提交的 HTML 尝试用
fetch向主站发带凭证请求，SameSite会直接拦住，不需要额外 JS 拦截逻辑
真正卡住权限的，从来不是 HTML 运行框里的代码，而是服务端响应头是否严格、Cookie 作用域是否最小化、以及网关是否在请求入口就否决高危模式。任何试图在前端 JS 层“模拟权限系统”的做法，都会被绕过。
