gin框架默认不提供csrf、xss、sql注入等安全防护，gin.default()仅加载日志与panic恢复中间件，开发者必须显式添加参数化查询、html/template自动转义、csrf令牌机制及secure cookie配置等防御措施。
Gin 本身不内置 CSRF、XSS、SQL 注入等防护逻辑，所有安全机制必须由开发者显式添加中间件或在业务层控制；依赖默认配置等于裸奔。
为什么 gin.Default() 不等于安全启动
调用 gin.Default() 只是加载了两个基础中间件：gin.Logger() 和 gin.Recovery()，前者打日志，后者捕获 panic 防止服务崩溃——这两者和安全无关。它不会自动设置 CSP 头、不校验 Cookie 签名、不转义输出、不拦截恶意参数。
常见错误现象：本地开发一切正常，上线后被扫描出 XSS 漏洞、登录接口遭暴力爆破、表单提交被 CSRF 攻击绕过。
- 不要把日志/恢复中间件误认为安全中间件
- 没有手动启用
SecureCookie或签名机制时，c.SetCookie()写出的 Cookie 是明文且可篡改的 -
gin.Context.PostForm()返回原始字符串，不做任何过滤，直接拼 SQL 或写入 HTML 就是高危操作
CSRF 防御必须手动实现双重提交 Cookie
Gin 不提供开箱即用的 CSRF token 管理。若需防御，必须自己生成、签发、校验，且必须确保 Cookie 的 HttpOnly + SameSite=Strict + Secure（HTTPS 环境下）三者齐备。
典型实现要点：
- 生成 token 推荐用
crypto/rand.Read()而非math/rand，避免可预测性 - 设置 Cookie 时必须指定
MaxAge，不能只靠Expires（部分客户端行为不一致） - 校验中间件应统一放在路由组顶层，比如
api := r.Group("/api", csrfMiddleware)，而非每个 handler 单独写 - 前端必须从响应头或隐藏字段读取 token，并通过
X-CSRF-Token请求头发送，不能从 document.cookie 读（违反 HttpOnly 原则）
输出上下文决定转义方式，html/template 不能省
Gin 的 c.String()、c.JSON()、c.XML() 都不处理 XSS，它们只是封装了响应写入逻辑。真正防 XSS 的是 Go 标准库的 html/template 包，且必须用对上下文。
错误做法示例：
c.String(200, "<div>%s</div>", userInput) // 直接插值，XSS 高危
正确做法：
- HTML 输出：用
html/template，且模板中使用{{.}}（自动转义）而非{{. | safeHTML}} - JS 上下文输出：不能靠模板自动转义，需用
js.Marshal()或手动strings.ReplaceAll()处理引号和反斜杠 - URL 参数插入：用
url.QueryEscape()，不是html.EscapeString() - 永远不要在模板里拼接用户输入的 HTML 片段，哪怕加了
template.HTML类型转换
Cookie 安全配置项漏一不可
Gin 设置 Cookie 的 c.SetCookie() 方法有 7 个参数，其中 secure、httpOnly、sameSite 这三项一旦缺失，在生产环境就构成实际风险。
关键参数含义与建议值：
-
secure：生产环境必须为true（仅 HTTPS 传输），开发环境可设false，但不能省略传参 -
httpOnly：涉及 session、token 的 Cookie 必须为true，禁用 JS 访问 -
sameSite：推荐http.SameSiteStrictMode（防 CSRF 更严），或http.SameSiteLaxMode（兼容性更好） -
maxAge：明确设值（如3600），不要传0（会变成会话级 Cookie，关浏览器才失效，不利于 token 主动吊销）
最容易被忽略的是 sameSite 参数——Go 1.11+ 才支持，旧项目若未升级 net/http 或未显式传参，该字段默认为空，浏览器按宽松策略处理，CSRF 防御形同虚设。
