Fiber 默认不防 SQL 注入和 XSS，因其仅作路由分发，安全需手动加固：db.Query 拼接用户输入会导致注入，必须用参数化查询；html/template 仅对 {{.Foo}} 自动转义，其他输出方式均需自行防护；所有安全响应头、Cookie 属性及输入校验均须显式配置。
Fiber 默认不防 SQL 注入和 XSS，必须手动加固——它只做路由分发，不碰安全逻辑。
为什么 Fiber 的 db.Query("SELECT * FROM user WHERE id = " + id) 会出事
Fiber 是 HTTP 路由层，db.Query 调用的是底层驱动（如 database/sql），如果直接拼接用户输入，攻击者传 id=1 OR 1=1 -- 就能绕过条件查全表。
- 永远不要用
fmt.Sprintf或字符串拼接构造 SQL 查询 - 必须用
db.Query("WHERE id = ?", id)或db.Prepare绑定参数 - 若用 ORM（如 GORM），确保启用
PrepareStmt: true，否则部分场景仍可能退化为拼接 - 对数字型参数，额外用
strconv.Atoi强转并检查错误，避免空值或非数字被透传进查询
html/template 里 {{.UserInput}} 为什么没被自动转义
Fiber 不强制你用 html/template，如果你用 text/template、fmt.Fprintf(c.Response().BodyWriter(), ...) 或直接返回 JSON，XSS 就在等你。
- 仅
html/template对{{.Foo}}做自动 HTML 转义；{{.Foo | safeHTML}}才绕过 - 返回 JSON 时，别把用户输入直接塞进
map[string]interface{}再c.JSON(200, data)—— 浏览器不会解析 JSON 里的脚本，但前端 JS 若用innerHTML渲染该字段，XSS 立刻触发 - 富文本场景必须用净化库（如
bluemonday），不能只靠html/template - 所有响应头需手动加：
X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Content-Security-Policy
怎么给 Fiber 加上 CSP 和 XSS 保护头
Fiber 没内置安全中间件，gin.Default() 那种“默认带点防护”的事它不做——你得自己注册中间件或在每个 handler 里写 c.Set(...)。
- 统一加头推荐用中间件：
app.Use(func(c *fiber.Ctx) error { c.Set("X-Content-Type-Options", "nosniff"); c.Set("X-Frame-Options", "DENY"); return c.Next() }) - CSP 头要按实际资源来源配，比如只允许加载自身脚本：
c.Set("Content-Security-Policy", "default-src 'self'; script-src 'self' https://cdn.example.com") - 别依赖
X-XSS-Protection：现代浏览器已弃用，Chrome 78+ 完全忽略 - Cookie 必须设
HttpOnly+Secure+SameSite=Lax（生产环境启 HTTPS 后）
最易被忽略的点：Fiber 的 c.Params("id")、c.Query("q")、c.Body() 全是原始字节，不做任何过滤。你得自己决定在哪一层做校验——是在中间件里统一白名单校验，还是在 handler 里按字段类型分别处理。没有“默认安全”，只有“你写的每行代码都得扛住恶意输入”。
