Gin本身不提供Cookie防篡改机制，c.SetCookie()写出的Cookie默认明文、无签名、可被客户端任意修改，仅依赖其做身份校验极易被绕过；需借助gorilla/securecookie等库实现HMAC签名，并配合httpOnly、Secure等属性及服务端校验才能保障安全。
Gin 本身不提供 Cookie 防篡改机制，c.SetCookie() 写出的 Cookie 默认是明文、无签名、可被客户端任意修改的 —— 这意味着仅靠 SetCookie 和 Cookie 两个函数做身份校验或敏感状态存储，极易被绕过。
为什么直接用 SetCookie 存 session ID 或权限标记很危险
攻击者打开浏览器开发者工具，手动编辑 document.cookie = "role=admin"，再发请求，服务端若只依赖 c.Cookie("role") 做判断，就会误信该值。这不是 Gin 的 bug，而是 HTTP Cookie 协议本身的限制：浏览器发送什么，服务器就收到什么。
-
httpOnly: true只防 XSS 读取，不防手动修改或抓包重放 -
secure: true只保证传输加密，不保证内容可信 -
maxAge和expires控制生命周期，但时间戳可被客户端系统时间干扰（尤其移动端） - 没有签名机制，value 字段完全由客户端控制
真正防篡改的方案：用签名 Cookie（signed cookie）
Gin 自身不内置签名逻辑，必须借助第三方库或自己实现 HMAC 签名。最常用且轻量的是 gorilla/securecookie，它对 value 进行加密+签名，生成形如 xxx|yyyyyy 的带校验码的 Cookie。
- 签名密钥必须保密且长度 ≥ 32 字节（如
[]byte("32-byte-secret-key-here-1234567890")） - 服务端写 Cookie 时调用
Encode(name, value)，读取时用Decode(name, encodedValue)校验并解包 - 一旦客户端篡改 value 或签名部分，
Decode()直接返回 error，不会解析出脏数据 - 不要把敏感字段（如 role、is_admin）直接塞进 value —— 即使签名了，也建议只存不可逆标识（如 user_id），再查 DB 做权限判定
c.SetCookie() 和签名 Cookie 混用的常见坑
有人试图在 c.SetCookie() 里塞签名后的字符串，结果发现 Cookie 被截断或乱码 —— 这是因为 SetCookie 不处理编码，而签名后字符串可能含特殊字符（如 =、+、/）或超长（Base64 后膨胀约 33%）。
- 正确做法：用
securecookie.Encode()得到安全字符串后，再传给c.SetCookie(name, encoded, ...) - 务必设置
httpOnly: true，防止 JS 读取后泄露签名串 - 避免在
domain上设宽泛值（如".example.com"），否则子域间 Cookie 可能被跨站读取，削弱签名保护效果 - 签名密钥一旦泄漏或轮换，旧 Cookie 全部失效 —— 生产环境需配套密钥管理策略
防篡改的关键不在“怎么存”，而在“谁来验证、怎么验证”。Gin 的 Cookie() 函数只是管道，真正起作用的是你是否在读取后做了不可绕过的校验步骤 —— 签名只是其中一环，后面通常还要查数据库、比对时间戳、检查绑定设备指纹等。
