直接加密 Cookie 值不能防篡改，必须结合签名机制：服务端生成时既加密内容又附加 HMAC 签名，接收时先验签再解密；签名用密钥和 SHA-256 生成“数字指纹”，加密用 AES-256-GCM 保护敏感字段，密钥分离且安全加载；同时设置 HttpOnly、Secure、SameSite 和有效期，并在请求入口原子化验签，失败即拒。
直接加密 Cookie 值不能防篡改，必须结合签名机制。核心逻辑是：服务端生成 Cookie 时，既加密内容（防泄露），又附加不可伪造的签名（防篡改），接收请求时先验签再解密——签名不通过就直接拒绝，不进入后续处理。
用 HMAC 签名确保数据完整性
签名不是为了隐藏内容，而是为原始数据绑定一个“数字指纹”。攻击者即使看到 Cookie 格式，也无法在不知道密钥的前提下生成合法签名。
- 服务端拼接明文数据（如
userID=12345&role=user）后，用密钥和 SHA-256 计算 HMAC 值 - 将原始数据与 Base64 编码后的签名拼接，例如：
userID=12345&role=user.abc123xyz - 客户端提交该 Cookie 后，服务端拆分出数据部分和签名部分，重新计算 HMAC 并比对
- 使用
hmac.compare_digest()（Python）或等效安全比较函数，避免时序攻击
结合 AES 加密保护敏感字段
签名只防改，不防读；加密只防读，不防替。两者缺一不可。比如用户角色、过期时间这类信息，明文签名后仍可能被分析利用。
- 优先将结构化数据（如 map 或 struct）序列化为 JSON，再用 AES-256-CBC 或 AES-GCM 加密
- 加密密钥（32 字节）与签名密钥（64 字节）必须分离，且都应来自安全随机源
- 避免硬编码密钥，从环境变量或密钥管理服务加载，如：
os.Getenv("COOKIE_HASH_KEY") - GCM 模式更优：它原生支持认证加密（AEAD），一次运算同时完成加密与完整性校验
设置关键安全属性阻断常见攻击路径
再强的加密签名，若传输或存储环节松懈，也会前功尽弃。必须同步收紧 Cookie 的运行时行为。
- HttpOnly = true：阻止 JavaScript 读取，大幅降低 XSS 导致的 Cookie 泄露风险
- Secure = true：强制仅通过 HTTPS 传输，防止中间人明文截获
- SameSite = Strict 或 Lax：抑制跨站请求携带 Cookie，缓解 CSRF 攻击
- Max-Age 或 Expires：设合理有效期，避免长期有效 Cookie 成为持久攻击入口
验证流程必须原子化且早失败
签名验证不是可选步骤，而是请求处理的第一道闸门。任何绕过验签就解密或解析的行为，都会让整个防护失效。
- 收到请求后，立即提取 Cookie 值，执行完整验签逻辑
- 验签失败时返回 400 或 401，不记录日志细节（避免泄露验证逻辑），不调用下游业务代码
- 推荐使用成熟库封装流程，如 Go 的
gorilla/securecookie、Node.js 的cookie-parser（启用 signed 选项）、Laravel 的EncryptCookies中间件 - 定期轮换密钥，并兼容旧密钥做渐进式迁移，避免用户会话批量失效
