javascript无法防止cookie被篡改，关键防线必须由后端实现：httponly+secure+samesite组合、服务端签名验证、敏感数据不存cookie，前端仅负责安全传递。
JavaScript 本身无法防止 Cookie 被用户恶意篡改——因为前端运行环境完全可控，任何加密、混淆或校验逻辑都可被绕过。真正有效的防护不是“阻止篡改”，而是“让篡改失效”。核心思路是：服务端主导验证，前端只做传递，不参与敏感逻辑。
前端无法防篡改，但可以配合防滥用
- 浏览器不提供 JS 层面的防写入或签名验证能力
-
document.cookie是开放接口，用户随时可用开发者工具修改值 - 所有前端校验（如 base64 解码后比对哈希）均可被跳过或重放
所以重点不在“怎么拦住”，而在“怎么让改了也没用”。
关键防线必须由后端实现
-
HttpOnly + Secure + SameSite 是基础组合
deep-java-review下载Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
HttpOnly：确保敏感 Cookie（如 session_id）根本不出现在document.cookie中，JS 读不到、改不了 -
Secure：强制仅 HTTPS 传输，防中间人窃取或注入 -
SameSite=Lax/Strict：限制跨站请求携带 Cookie，大幅降低 CSRF 风险
-
-
签名或加密由后端完成
- 例如 JWT 或自定义 token，服务端用密钥生成 HMAC-SHA256 签名，拼在 Cookie 值后（如
session=abc123.hmac） - 每次请求时，后端重新计算签名比对；不一致则直接拒绝，前端改了也白改
- 例如 JWT 或自定义 token，服务端用密钥生成 HMAC-SHA256 签名，拼在 Cookie 值后（如
-
敏感字段绝不存入 Cookie
- 用户名、手机号、权限列表等明文信息不应出现在 Cookie 中
- 这些数据应在登录验证通过后，由后端按需返回 API 响应体，并通过 HTTPS 加密传输
前端能做的实际配合
- 登录成功后，不手动存 token 到 localStorage/sessionStorage，而是信任服务端下发的 HttpOnly Cookie
- 若需前端读写非敏感 Cookie（如 theme=dark、lang=zh），确保值不含业务关键信息
- 写入时显式设置
path=/和Secure（HTTPS 环境下），避免因路径不匹配导致后续读取失败 - 删除 Cookie 时，
path和domain必须与写入时完全一致，否则删不掉
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
