javascript操作cookie需配置secure、samesite和path属性防xss与csrf,httponly字段前端不可读,敏感数据不应存于cookie。

JavaScript 通过 BOM 的 document.cookie 接口读写 Cookie,但这个接口本身不安全、不直观,直接操作容易出错或引入风险。真正“安全”的读写,关键不在语法是否正确,而在于是否规避 XSS 窃取、是否限制传输范围、是否避免存储敏感内容——这些都依赖属性配置和使用逻辑,而非单纯调用 API。
写入 Cookie:必须带安全属性,不能裸奔
仅执行 document.cookie = "token=abc" 是危险的。生产环境必须显式设置以下三项:
-
Secure:确保只在 HTTPS 下发送,防止明文窃听。写法为
; Secure(注意分号前置) -
SameSite:推荐设为
Lax或Strict,阻断跨站请求携带 Cookie,防 CSRF。写法如; SameSite=Lax -
Path:明确限定作用路径,比如后台系统统一用
; path=/admin,避免前台页面误读
不建议手动拼字符串。封装一个安全写入函数更可靠:
function setSafeCookie(name, value, days = 7) {
const date = new Date();
date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000);
document.cookie = `${encodeURIComponent(name)}=${encodeURIComponent(value)}; ` +
`expires=${date.toUTCString()}; ` +
`path=/; ` +
`Secure; ` +
`SameSite=Lax`;
}
读取 Cookie:无法绕过 HttpOnly,别试图取敏感字段
document.cookie 返回的只是“JS 可见的 Cookie 列表”——如果服务端设置了 HttpOnly(如 session ID),它根本不会出现在这个字符串里。这是设计使然,不是 bug。
读取时需注意:
- 所有值都是 URL 编码的,必须用
decodeURIComponent()解码,否则中文或特殊字符会乱码 - 解析要按
;分割,再逐个trim()和=拆分,避免空格干扰 - 不要在前端解析 token、密码、用户身份等敏感字段;这类数据应由后端签发并校验,前端只存非敏感标识(如 user_id)
推荐读取函数:
function getCookie(name) {
const cookies = document.cookie.split(';');
for (let i = 0; i <h3>删除 Cookie:靠过期时间,且路径必须匹配</h3><p>删除的本质是覆盖:把同名 Cookie 的 <code>expires</code> 设为过去时间,并确保 <code>path</code>(和 <code>domain</code>,如果当初设过)与写入时完全一致,否则删不掉。</p>
- 常见错误:写入时用了
path=/user,删除时却用path=/,结果残留 - 稳妥做法:删除函数默认传入相同 path,或从原始写入逻辑中复用配置
- 示例:
function deleteCookie(name, path = '/') {
document.cookie = `${name}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=${path}`;
}
替代方案:优先考虑现代存储,而非硬刚 Cookie
Cookie 不是万能存储。它天生有 4KB 限制、每次请求自动携带、易受 XSS 影响等缺陷。
- 用户偏好、主题、语言等非敏感状态 → 用
localStorage更轻量、容量大、无网络开销 - 短期会话标识(如登录态临时凭证)→ 后端签发 JWT,前端存在
localStorage或内存变量,配合HttpOnlyrefresh token 使用 - 需要浏览器自动携带的认证凭证 → 仍用 Cookie,但务必配齐
Secure + HttpOnly + SameSite,且值不包含明文密码或 token payload - Chrome 87+ 支持
cookieStoreAPI,提供 Promise 化、事件监听能力,但兼容性有限,暂不适合作为唯一方案
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











