仅靠 gin 自身无法防 xss，必须组合输入校验、输出转义（用 html/template）和安全响应头（如 csp、httponly/secure cookie）三者才有效；gin 的 c.query 等方法原样读取数据，不做过滤，直接渲染将导致反射型 xss。
直接结论：仅靠 Gin 自身无法防 XSS，必须组合输入校验 + 输出转义 + 安全响应头三者才有效。
为什么 c.Query 或 c.PostForm 拿到的数据不能直接渲染
因为这些方法只是“原样读取”，不做过滤、不验证、不清理。比如用户提交 <script>alert(1)</script>，Gin 会照单全收，后续若直接塞进 HTML 模板或 JSON 响应里，就可能触发反射型 XSS。
- 常见错误现象：页面弹窗、cookie 被盗、跳转恶意链接
- 关键误区：以为“前端做了过滤”或“只允许字母数字”就安全——攻击者可绕过前端，直接发请求
- 正确做法：所有入口（
Query、PostForm、BindJSON）都视为不可信，必须显式处理
输出阶段必须用 html/template，禁用 text/template
html/template 是 Go 标准库中唯一提供上下文敏感自动转义的模板引擎。它会根据变量插入位置（HTML 文本、属性值、JS 字符串等）选择对应转义规则，比如把 变成 <code><。
- 错误写法：
template.Must(template.New("t").Parse(`<div>{{.Name}}</div>`))—— 若没指定html/template，默认是text/template，无转义 - 正确写法：
tmpl := template.Must(html.New("t").Parse(`<div>{{.Name}}</div>`)) - 若必须插入可信 HTML（如后台审核过的富文本），先用
bluemonday过滤，再用template.HTML包装，绝不可对原始用户输入调用| safeHTML
设置 Content-Security-Policy 头是低成本强防护
CSP 是浏览器端最后一道防线，能阻止未授权脚本执行，即使 XSS payload 被注入成功，也可能被拦截。
- 最简有效配置：
w.Header().Set("Content-Security-Policy", "default-src 'self'; script-src 'self'") - 不要漏掉
default-src 'self'，否则图片、样式等资源可能加载失败 - 避免宽泛策略如
script-src *或unsafe-inline，它们会直接废掉 CSP 效果 - Gin 中可在全局中间件里统一设置：
c.Header("Content-Security-Policy", "...")
SetCookie 的 HttpOnly 和 Secure 参数不是可选项
Cookie 是 XSS 后最常被窃取的目标，尤其是 session ID。不设 HttpOnly，攻击者用 document.cookie 就能一键获取；不设 Secure，HTTP 明文传输时 cookie 会被截获。
- 正确调用示例：
c.SetCookie("session_id", token, 3600, "/", "example.com", true, true) -
HttpOnly: true→ JS 无法读取，大幅降低 XSS 利用价值 -
Secure: true→ 仅 HTTPS 传输，防止中间人窃取 - 本地开发调试时若用 HTTP，
Secure必须设为false，但上线前务必改回true
真正容易被忽略的不是某一行代码，而是“信任链断裂”——比如后端用 html/template 渲染了，但前端 JavaScript 又用 innerHTML = data 二次拼接；或者 API 返回 JSON 时加了 CSP，但 HTML 页面本身没设。XSS 防护必须贯穿整个数据流，任一环节松动，前面所有努力都可能白费。
