Cookie防篡改本质是服务端校验而非前端限制，需通过签名机制（如HMAC-SHA256）保障内容完整性、HttpOnly/Secure/SameSite属性降低攻击面，并严禁将权限、金额等敏感逻辑交由客户端Cookie决定，所有关键操作必须服务端查库或可信存储二次验证。
JavaScript 本身无法真正防止用户手动篡改 Cookie —— 因为 document.cookie 是客户端可读写的，任何前端存储（包括 Cookie、localStorage）都可被开发者工具直接修改。所谓“防篡改”，本质是**不让篡改产生实际业务危害**，关键在于服务端校验和设计逻辑隔离。
服务端必须验证所有敏感状态
前端写入的 Cookie（比如 user_role=guest 或 balance=100）仅作标识或缓存用，绝不能作为权限判断或金额计算的唯一依据。
- 每次请求涉及权限、金额、状态变更时，后端需重新查数据库或可信会话存储（如 Redis 中的 session），而非信任 Cookie 值
- 例如：用户把
role=admin写进 Cookie，后端收到请求后仍要查该用户真实角色，再决定是否允许操作 - 敏感操作（如转账、删账号）必须二次校验（短信/邮箱确认、token 时效性、行为风控）
用签名机制保障 Cookie 内容完整性
服务端生成 Cookie 时附加签名，客户端无法伪造或修改有效值。
- 典型做法：将数据 + 密钥用 HMAC-SHA256 签名，拼接成
data.signature - 例如：
user_id=12345.expiry=1721598000.hmac_abcd1234... - 前端可读写，但服务端每次解析前先验证签名是否匹配；一旦篡改，签名失效，直接拒绝
- JWT 就是这种思路的标准化实现，推荐用于身份凭证类 Cookie
合理使用 HttpOnly + Secure + SameSite 属性
这些属性虽不防用户改，但能大幅降低篡改入口和危害面：
立即学习“Java免费学习笔记（深入）”；
- HttpOnly：阻止 JS 读取敏感 Cookie（如 session_id），避免 XSS 后自动窃取或注入
- Secure：确保 Cookie 只走 HTTPS，防止中间人劫持或明文篡改
- SameSite=Lax / Strict：阻断跨站请求携带 Cookie，让伪造请求无法附带有效态
- 注意：SameSite=None 必须搭配 Secure，否则现代浏览器会拒绝设置
前端只存非敏感、可丢失的状态
明确区分哪些信息适合放 Cookie，哪些不该放：
- ✅ 可放：语言偏好、主题模式、上次搜索关键词（丢失不影响核心功能）
- ❌ 禁放：用户 ID（未签名）、余额、权限等级、登录态令牌（应由 HttpOnly Cookie 承载）
- 若必须前端读写状态，优先用 localStorage + 服务端最终一致性校验，而非依赖 Cookie 值做逻辑分支
