go web安全需主动防御xss、csrf和认证漏洞：xss要慎用safehtml并区分上下文编码；csrf令牌须绑定会话且严格校验；session与jwt需按场景选型并规范存储与登出；还需禁用调试信息、限流请求体、设置安全响应头。
Go 语言开发 Web 应用时，安全不能靠框架“自动兜底”，很多防护需开发者主动介入。跨站脚本（XSS）、跨站请求伪造（CSRF）和认证机制是三类高频风险点，处理不当轻则数据泄露，重则账户接管。
防止 XSS：输出上下文决定转义方式
Go 标准库 html/template 是防御反射型/存储型 XSS 的核心工具，但它不会自动识别上下文——在 HTML 标签、JavaScript 字符串、CSS 属性或 URL 中插入数据，所需转义规则完全不同。
正确做法是：始终使用 html/template（而非 text/template），并根据插入位置选择合适的方法：
- 插入 HTML 内容 → 用 {{.Content}}（自动 HTML 转义）
- 插入 JavaScript 字符串 → 先用 json.Marshal 序列化，再在模板中用 {{.Data | js}}
- 插入 URL 参数 → 使用 {{.URL | urlquery}}（注意不是 url 函数）
- 绝对禁止拼接用户输入到模板中：{{"<script>"+.Raw+"</script>"}} 这类写法会绕过所有保护
抵御 CSRF：为状态变更请求添加一次性令牌
CSRF 攻击依赖浏览器自动携带 Cookie 发起请求，对 POST/PUT/DELETE 等非幂等操作必须验证请求来源可信。Go 生态中推荐使用 gorilla/csrf 或 gofrs/uuid + 自建中间件。
立即学习“go语言免费学习笔记（深入）”；
关键实践包括：
- 仅对非 GET/HEAD 请求校验 CSRF 令牌（GET 应保持无副作用）
- 令牌需绑定用户 Session，且单次有效或短期有效（如 2 小时）
- 前端表单中通过 hidden 字段提交：
- AJAX 请求需从 meta 标签或 API 获取令牌，并通过 X-CSRF-Token 请求头发送
认证机制：Session 管理与 Token 设计要兼顾安全与可用
基于 Session 的登录需避免常见陷阱：默认使用内存存储（重启丢失）、未设置 Secure/HttpOnly/SameSite 属性、Session ID 泄露。
建议配置：
- Session 存储用 Redis 或 PostgreSQL，禁用内存后端
- Cookie 设置：Secure=true（仅 HTTPS）、HttpOnly=true（防 JS 访问）、SameSite=Strict 或 Lax（防 CSRF 关联）
- 登录成功后强制生成新 Session ID（防止会话固定）
- JWT 若用于认证，应仅存必要字段（如 user_id、exp），签名密钥长度 ≥256 位，且服务端必须校验 iat 和 nbf 字段
补充要点：别忽略基础但致命的细节
很多漏洞源于低级疏忽：
- 路由中间件顺序错误：认证中间件必须在日志、恢复 panic 之后，但在业务 handler 之前
- 密码哈希必须用 bcrypt 或 scrypt，禁用 MD5/SHA 等快速哈希
- 错误信息不泄露内部结构：登录失败统一返回“用户名或密码错误”，不区分是用户不存在还是密码错
- 敏感接口加速率限制（如 /login、/reset-password），用 golang.org/x/time/rate 实现令牌桶
