JavaScript无法防止Cookie篡改，签名机制使服务端能识别篡改并拒绝请求；服务端用HMAC-SHA256基于密钥和原始值生成签名，拼接后下发，验证时重算比对，不一致则丢弃，配合HttpOnly、Secure、SameSite等属性增强防护。

JavaScript 本身不能阻止用户修改 Cookie，签名机制的作用是让服务端能立刻识别出篡改行为，从而拒绝非法请求。关键不是“前端防改”，而是“改了也白改”——服务端校验不通过，业务逻辑就走不通。

签名怎么生成和存储

服务端生成 Cookie 时，把原始值（如 user_id=12345）和密钥一起做 HMAC-SHA256 运算，得到签名字符串。然后把原始值和签名拼在一起，用分隔符（如 | 或 .）连接：

• user_id=12345|a1b2c3d4e5（常见于自定义实现）
• user_id=12345.20260729.hmac_f8a9b2（带时间戳+签名，更推荐）

这个完整字符串作为 Cookie 值写入浏览器。注意：签名部分不能由前端计算，必须由后端生成并下发。

服务端怎么验证签名

每次收到请求，服务端从 Cookie 中提取原始数据和签名两部分，再用相同密钥和算法重新计算签名，比对是否一致：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

立即学习“Java免费学习笔记（深入）”；

• 若一致，说明 Cookie 内容未被改动，可继续后续逻辑
• 若不一致，直接丢弃该 Cookie，当作未登录或会话失效处理
• 建议加入时间戳校验，比如只接受 15 分钟内生成的签名，防止重放攻击

前端 JavaScript 的角色很有限

前端只需正常读写 Cookie（如用 document.cookie），不参与签名计算或验证。但要注意：

• 避免把敏感字段（如 role=admin、balance=9999）明文塞进 Cookie
• 如果必须前端读取某些状态，优先用 HttpOnly + Secure 的 session_id，再由后端查库确认权限
• 不要在 JS 里解析或拼接签名 Cookie，容易出错且无实际防护意义

配合其他安全属性效果更好

签名只是完整性保障，还需叠加基础防护降低风险面：

• HttpOnly：防止 XSS 泄露 session_id 类关键 Cookie
• Secure：确保 Cookie 只走 HTTPS，避免中间人截获或篡改
• SameSite=Lax：减少跨站伪造请求携带有效 Cookie 的可能
• Max-Age / Expires：设合理过期时间，缩短被滥用窗口