Cookie 不能靠 Echo 框架“隐藏”，必须服务端主动脱敏：禁存明文敏感字段，改用短期有效会话令牌（如 UUID）+ Redis 关联用户信息，并严格设置 HttpOnly、Secure、SameSite 等属性。
Cookie 值不能靠 Echo 框架“隐藏”，必须由服务端主动脱敏
Echo 本身不提供 Cookie 内容隐藏或自动脱敏功能。所谓“隐藏”，实际是指避免在 Cookie 中存储明文敏感字段（如用户 ID、手机号、token 原值），而应改用不可逆映射或短期有效凭证。直接对 SetCookie 的 value 做字符串替换（比如把中间几位替换成 *）是无效的——浏览器仍可读取完整值，且可能破坏签名验证逻辑。
使用加密 + 签名防止篡改，而非“隐藏”
ThinkPHP 的 auto_encrypt 是个参考思路，但 Echo 没有内置等效机制。你得自己组合：gob 或 json 序列化结构体 → AES 加密 → base64 编码 → 写入 Cookie；读取时反向解密校验。关键点：
- 必须用服务端可控的密钥（如从环境变量读取的
AES_KEY），不能硬编码 - 务必加入时间戳和随机 nonce，防止重放攻击
- 解密失败时直接丢弃 Cookie，不要 fallback 到明文逻辑
- 别用
cookie.Value直接存用户邮箱——哪怕加了HttpOnly，泄露后仍可被服务端误用
敏感字段必须剥离，只留必要标识符
常见错误是把整个用户对象 JSON 化后塞进 Cookie。正确做法是只存一个短生命周期、单次有效的会话令牌（如 session_id=abc123），然后在 Redis 或数据库中关联真实用户信息。这样即使 Cookie 被截获，攻击者也无法直接还原身份。
具体操作建议：
- 登录成功后生成 UUID v4 作为
session_id，写入 Redis（带 TTL，比如 30 分钟） - Cookie 只设
session_id字段，Path=/、HttpOnly=true、Secure=true、SameSite=Strict - 每次请求用
c.Cookie("session_id")获取值，再查 Redis 验证有效性 - 登出时调用
c.SetCookie(&http.Cookie{... MaxAge: 0 })清除，并删 Redis 记录
前端无法真正“隐藏”，HttpOnly 是底线
只要没设 HttpOnly=true，JS 就能通过 document.cookie 读到所有非 HttpOnly Cookie。这是浏览器机制，Echo 控制不了。所以：
- 所有含敏感语义的 Cookie（如
user_role、auth_token）必须设HttpOnly=true - 不要依赖 JS 去“混淆”或“base64 编码”来“隐藏”——这些在控制台里两行代码就能还原
- 如果业务真需要前端参与鉴权（比如 WebSocket 连接携带 token），应改用 Authorization Header 传 bearer token，而不是放 Cookie
最易被忽略的是：Cookie 的 Domain 和 Path 设置不当会导致跨子域泄露；而 SameSite=Lax 在 2025 年已成为主流浏览器默认行为，若你的内部系统依赖跨站 POST 提交，得显式设为 SameSite=None 并确保 Secure=true，否则 Cookie 根本不会发送。
