Echo框架中Cookie默认可被XSS读取，必须显式设置HttpOnly=true才能阻止document.cookie访问；Secure和SameSite也需在生产环境强制启用以防范中间人攻击和CSRF。
echo框架中Cookie默认可被XSS读取
是的，Echo 默认设置的 Cookie 没有启用 HttpOnly 和 Secure，只要页面存在反射型或存储型 XSS 漏洞，攻击者就能用 document.cookie 直接读取（包括 Session ID 等敏感字段）。这不是 Echo 的 bug，而是 HTTP 协议层的默认行为：不显式声明防护属性，浏览器就允许 JS 访问。
必须手动设置 HttpOnly 才能阻止 document.cookie 读取
HttpOnly 是唯一能阻止 JavaScript 读取 Cookie 的机制。Echo 中设置它的方式很直接，但容易漏掉：
- 使用
c.SetCookie()时，第 7 个参数必须为true：c.SetCookie(&http.Cookie{ Name: "session_id", Value: "abc123", Path: "/", Domain: "example.com", MaxAge: 3600, HttpOnly: true, // ← 关键：必须显式设为 true Secure: true, // ← 生产环境也应开启 SameSite: http.SameSiteLaxMode, }) - 如果用
c.Cookie()读取，它只返回*http.Cookie，不包含原始设置值；HttpOnly的效果体现在浏览器端，服务端无法“看到”该标记 - 注意：
HttpOnly对单个 Cookie 生效，不是全局开关。你设了session_id的HttpOnly，不代表theme或lang也受保护
Secure 和 SameSite 不是可选项，而是生产环境强制项
Secure 和 SameSite 虽不防 document.cookie，但能大幅压缩攻击面：
-
Secure: true→ 强制 Cookie 只通过 HTTPS 传输，防止中间人嗅探明文 Cookie -
SameSite: http.SameSiteStrictMode或http.SameSiteLaxMode→ 阻断跨站请求携带 Cookie，对 CSRF 防御至关重要 - 开发环境常因没配 HTTPS 而跳过
Secure，但上线前必须补上；否则即使开了HttpOnly，Cookie 仍可能在 HTTP 请求中明文泄露
别依赖前端过滤或“只存非敏感数据”这种侥幸
很多人以为“我 Cookie 里只放 session_id，又没存密码，问题不大”，这是危险误区：
- Session ID 就是钥匙。拿到它，攻击者等于登录了用户账号，和拿到密码无异
- 即使你用了 JWT 存在 Cookie 里，只要没设
HttpOnly，JS 就能读、能发到第三方服务器 - DOM 型 XSS 同样能读取 Cookie——只要页面里有未转义的用户输入拼进 HTML，
document.cookie就随时可调用
真正难防的从来不是“能不能读”，而是“读完之后有没有后续动作”。HttpOnly 是第一道也是最廉价的防线，漏掉它，等于把门锁换成插销。
