Gin默认路由不防恶意请求，因其设计上将路径合法性校验交由业务层或中间件处理，而非框架内置；它完成URL解码和规范化后直接匹配路由，不对越界路径（如..%2f..%2fetc%2fpasswd）拦截。
为什么 Gin 的默认路由不防恶意请求
Gin 默认完全信任客户端传入的路径，GET /api/users/1 和 GET /api/users/..%2f..%2fetc%2fpasswd 都能匹配到同一个 GET("/api/users/:id") 路由——因为 Gin 在解析路径参数前就完成了 URL 解码和路径规范化，但不会拦截越界访问。这不是 bug，是设计取舍：Gin 把“路径合法性校验”留给了业务层或中间件。
用 gin.Recovery() 捕获 panic 但拦不住路径遍历
gin.Recovery() 只处理 handler 内部 panic（比如空指针、数组越界），对文件读取类的路径遍历攻击无感。比如你写 os.Open("/var/data/" + c.Param("id"))，传入 id=../../etc/passwd，程序照常打开文件，Recovery 根本不触发。
- 必须在拼接路径前做白名单校验或路径净化
-
filepath.Clean()不能直接信任——它只做标准化，不阻止越界，filepath.Clean("../../etc/passwd")返回/etc/passwd - 推荐用
filepath.Join()+strings.HasPrefix()双重检查：先拼出绝对路径，再确认是否仍在允许根目录下
实现一个轻量级路径白名单中间件
不要依赖第三方库做“全量安全防护”，Gin 场景下最稳的方式是明确声明哪些路径段合法。比如用户 ID 只允许数字，资源名只允许小写字母+下划线：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func PathParamSanitizer() gin.HandlerFunc {
return func(c *gin.Context) {
id := c.Param("id")
if !regexp.MustCompile(`^\d+$`).MatchString(id) {
c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid id format"})
return
}
c.Next()
}
}
r := gin.Default()
r.GET("/api/users/:id", PathParamSanitizer(), getUserHandler)
- 正则比
strconv.Atoi更安全：避免整数溢出导致的异常行为 - 若需支持 UUID，用
^[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}$ - 别在中间件里做
c.Param("id")以外的参数校验——Gin 不保证所有参数都通过:name形式定义，查询参数得另写逻辑
JWT 鉴权和路由防护不是一回事
很多人误以为加了 AuthRequired() 中间件就安全了，其实它只管“有没有权限”，不管“参数合不合法”。GET /api/admin/config?file=../../../etc/shadow 可能绕过 JWT 校验（如果 handler 本身没校验 query 参数）。
立即学习“go语言免费学习笔记（深入）”；
- 鉴权中间件应放在路径参数校验之后，形成“先格式合法 → 再身份可信 → 最后业务授权”链路
- 对
c.Query()、c.PostForm()等输入，同样需要独立校验，不能复用路径参数的正则 - 敏感接口（如文件下载、配置读取）建议禁用通配符路由，显式定义每条路径，比如用
GET("/download/log")而非GET("/download/:name")
r.StaticFS("/static", http.Dir("./public")) 若未设置 fs := http.Dir("./public") 的 clean wrapper，仍可能被 /static/..%2f..%2f/etc/passwd 绕过。Gin 1.9+ 已默认加固，但老版本或自定义 http.FileSystem 实现时，必须手动 wrap。 
