Iris本身不自动防SQL注入，防护必须主动实现：禁用字符串拼接SQL、统一校验所有输入（query/body/form），中间件须提前读取并检测敏感字符；GORM应严格使用参数化查询，动态字段需白名单校验。
直接结论：Iris 本身不自动防 SQL 注入，防护必须由你主动做——核心是「不拼 SQL 字符串」+「所有输入统一校验」，中间件里漏掉 body 或 form 就等于白防。
为什么只过滤 query 参数根本不够
很多人在中间件里只调 c.URLParam() 做检测，但攻击者早就不走 URL 了。现代 API 大量用 application/json 提交数据，或用 multipart/form-data 传文件+字段，这些内容 Iris 默认不解析，c.FormValue() 和 c.ReadBody() 都得你手动触发。不读，就压根看不到恶意 payload。
- 常见错误现象：
{"username": "admin' OR '1'='1", "password": "123"}这种 JSON 直接进 handler，如果后续拼 SQL，立刻中招 - 必须在中间件里提前调
c.ReadBody(&v)或c.FormValue("field")，再对每个字符串字段跑敏感字符检测 - 正则推荐用
(?i)<script>，注意大小写不敏感 + 多关键字覆盖</script> - 别信“前端已校验”——后端必须独立验证，且要拒绝超长字段（如单个值 > 10KB），防慢速攻击和日志刷屏
怎么安全地把参数传给 GORM 查询
GORM 本身能防注入，但前提是别绕过它。最危险的操作是：从请求里取到 id 后，手动拼成 "SELECT * FROM users WHERE id = " + id 再用 db.Raw() 执行。
- 正确做法：一律用 GORM 的链式方法，比如
db.Where("status = ?", status).First(&u)，问号占位符由 GORM 转成参数化语句 - 分页参数必须用
c.URLParamInt("page")和c.URLParamInt("size")，检查 error 并约束范围（if size > 100 { size = 100 }） - GORM 分页固定写法是
db.Offset((page - 1) * size).Limit(size)，顺序不能反，否则旧版 GORM 可能生成错 SQL - 绝对不要把
page或id转成 int 后再拼进 SQL 字符串——哪怕你认为“已经转整型很安全”，也破坏了参数化原则
Content-Type 不匹配时该怎么响应
攻击者常伪造 Content-Type 绕过某些解析逻辑。比如发 JSON 却声明 text/plain，导致中间件跳过 ReadBody，后续 handler 直接拿原始字节去解析，极易出问题。
- 关键接口（如登录、密码重置）应在中间件里显式校验：
if c.GetHeader("Content-Type") != "application/json" { c.StopWithStatus(iris.StatusNotAcceptable); return } - 别只 check 是否包含
json，要严格匹配预期值，避免application/json;charset=utf-8这类变体绕过 - 返回
406 Not Acceptable比400 Bad Request更准确，表明客户端用了服务端不支持的媒体类型 - 这个判断必须放在所有参数读取之前，否则可能已触发副作用（如日志记录、缓存写入）
真正容易被忽略的是：**GORM 的 Where 方法接受 map 或 struct 时，字段名若来自用户输入（比如动态排序字段 order_by=user_input），依然可能被利用**。这种场景必须白名单校验，不能只依赖参数化查询。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
