直接用SetCookie/Cookie不安全，因其仅做原始字符串读写，无签名、加密与完整性校验，攻击者可篡改值（如role=admin→guest）且服务端照单全收；真正安全的Cookie需服务端自动签名防篡改、验证签名拒收被改数据，并可选加密防明文泄露。
为什么直接用 SetCookie 和 Cookie 不算“安全”
因为这两个方法只做原始字符串读写，不加密、不签名、不校验完整性。攻击者可篡改 Cookie 值（比如把 "role=admin" 改成 "role=guest"），服务端照单全收——这根本不是“安全 Cookie”，只是普通 Cookie。
真正安全的 Cookie 必须满足：
- 服务端写入时自动签名（防篡改）
- 服务端读取时验证签名（拒绝被修改的值）
- 可选加密（防明文泄露，如敏感 token）
Gin 自带的 SetCookie/Cookie 不提供这些能力，必须引入额外机制。
用 gorilla/securecookie 实现签名+可选加密
这是最轻量、最常用、且被 Gin 社区广泛验证的安全 Cookie 方案。它不依赖 session 存储，纯客户端加密/签名，适合存储小量可信数据（如用户 ID、角色、登录态标识）。
关键步骤：
- 初始化一个
securecookie.Encoder，传入至少 32 字节的密钥（hashKey用于签名，blockKey用于 AES 加密） - 写入前用
Encode()包装原始值（自动签名，加了加密则同时加密） - 读取后用
Decode()解包并校验签名（失败直接返回 error）
示例片段：
import "github.com/gorilla/securecookie"
var cookieEncoder = securecookie.New(
[]byte("32-byte-hash-key-for-signature"), // hashKey
[]byte("32-byte-block-key-for-encryption"), // blockKey
)
func setSecureCookie(c *gin.Context, name, value string) {
encoded, err := cookieEncoder.Encode(name, value)
if err != nil {
c.AbortWithStatus(500)
return
}
c.SetCookie(name, encoded, 3600, "/", "", false, true)
}
func getSecureCookie(c *gin.Context, name string) (string, error) {
cookie, err := c.Cookie(name)
if err != nil {
return "", err
}
var value string
if err = cookieEncoder.Decode(name, cookie, &value); err != nil {
return "", err // 签名无效或解密失败，直接拒绝
}
return value, nil
}
常见踩坑点：路径、域名、SameSite 必须严格匹配
即使用了 securecookie，如果 SetCookie 的 path、domain 或 SameSite 设置与读取时不一致，浏览器可能根本不发送该 Cookie，导致 c.Cookie() 返回 http.ErrNoCookie —— 这和安全性无关，但会让“安全读写”失效。
-
path：生产环境别写"/"就完事，要和前端实际请求路径前缀一致（比如 API 全在/api/下，就设path="/api/"） -
domain：本地开发用"localhost"，上线必须填真实域名（如"example.com"），不能带http://或端口 -
SameSite：Gin 原生SetCookie不支持该参数，需手动设置响应头：c.Header("Set-Cookie", fmt.Sprintf("%s=%s; Path=/; Domain=example.com; SameSite=Lax; HttpOnly; Secure", name, encoded))
什么场景不该用安全 Cookie？
安全 Cookie（尤其是加密型）只适合存小量、低敏感、可重建的数据。以下情况请绕开：
- 存完整 JWT token：JWT 本身已签名，再套一层加密是冗余，且增加解析开销
- 存用户密码、银行卡号等高敏信息：服务端绝不应把这些写进 Cookie，无论是否加密
- 存大对象（>1KB）：浏览器对单个 Cookie 有 4KB 限制，
securecookie编码后体积膨胀约 2–3 倍 - 需要服务端主动失效：签名 Cookie 无法“吊销”，只能靠过期时间控制；真要主动登出，得配 session 存储 + token 黑名单
真正难的不是加密，而是判断哪些数据值得放进去、哪些必须留在服务端。一旦混淆边界，安全机制反而会给人虚假安全感。
