Revel框架不自动校验参数安全，必须显式调用Validation或白名单规则；c.Validation仅支持运行时字段检查，需手动处理空字符串、正则、类型转换及错误保留；查询参数须在c.Params.Get后立即校验，防止SQL注入/XSS；生产环境应优先采用网关+中间件的白名单前置校验，并同步维护路由文档、规则配置与前端约束。
Revel 框架本身不自动执行参数安全校验，必须显式调用 Validation 方法或结合白名单规则手动拦截——依赖框架默认行为会直接暴露 SQL 注入、XSS 等风险。
用 c.Validation 做基础字段级校验
Revel 提供的 Validation 是运行时检查机制，不是声明式约束，需在控制器中逐字段调用：
-
c.Validation.Required(name)检查非空，但不会拒绝空字符串（需额外strings.TrimSpace） -
c.Validation.Match(name, regexp.MustCompile("^[a-zA-Z0-9_]{4,15}$"))必须自己写正则，不能复用全局白名单规则 -
c.Validation.MinSize(value, 1)和c.Validation.MaxSize(value, 100)对数字类型无效，只适用于字符串 - 所有验证结果存于
c.Validation.Errors，调用c.Validation.HasErrors()后必须立刻c.Validation.Keep()才能跨重定向保留错误信息
查询参数必须在 c.Params.Get() 后立即校验
Revel 把 ?name=abc&id=123 自动注入 c.Params，但不会自动过滤或转义。常见疏漏：
- 直接用
c.Params.Get("id")拿到字符串后，未转成int就传给DB.Where("id = ?", id)—— 攻击者可传id=1%20OR%201=1绕过类型检查 -
c.Params.Get("sort")用于 ORDER BY 子句时，未限定为预设枚举（如["created_at", "name"]），导致 SQL 注入 - 对
c.Params.Get("page")只做strconv.Atoi，没限制范围（应限定 1–1000），易引发深度分页性能问题或整数溢出
绕过 Validation 直接上白名单规则
内建 Validation 缺乏上下文感知能力，生产环境建议跳过它，改用白名单驱动的前置校验：
- 在中间件或
Interceptor中统一处理：解析请求后，对每个参数按类型匹配规则，例如email字段必须满足^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$ - 数值参数不用
MinSize/MaxSize，而用strconv.ParseInt(s, 10, 64)+ 范围判断，避免字符串长度误判 - 枚举值用
map[string]bool{"active": true, "inactive": true}查表，比正则更安全、更快 - 文件类参数（如上传头像）必须同时校验
Content-Type头、实际文件头（magic bytes）和扩展名三者一致，仅靠c.Params.Get("filename")完全不可信
校验位置决定安全性上限
校验放在哪里，决定了攻击面大小：
- 在 DAO 层（如
DB.Where前）做校验＝已进入业务流程，WAF 日志里全是“已放行”的攻击流量 - 在控制器开头做
c.Params.Get+ 校验＝仍可能被绕过（比如通过 multipart/form-data 伪造同名字段） - 最佳实践是网关层（Nginx 或 Kong）先做粗筛（如拒绝
id含;、--、/*的请求），再由 Revel 中间件做细粒度白名单匹配 - 敏感操作（如
DELETE /user/123）必须叠加CSRF Token验证，不能只信 URL 参数
真正难的不是写校验逻辑，而是每新增一个接口字段，都要同步更新三处：路由文档、白名单规则配置、前端提交约束。漏掉任意一环，白名单就形同虚设。
