当前位置：首页 > 文章列表 > Golang > Go教程 > Golang防范SQL注入技巧解析

Golang防范SQL注入技巧解析

2026-04-25 21:27:51 0浏览收藏

本文深入剖析了Go语言中防范SQL注入的核心策略，强调杜绝字符串拼接、严格使用database/sql的参数化Query/Exec调用，并针对不同数据库驱动（MySQL用?、PostgreSQL用$1）适配占位符；明确指出动态表名、字段名、排序子句等无法参数化的场景必须依赖白名单校验，而非依赖预处理或ORM“自动防护”——GORM、sqlc等工具若误用字符串拼接或裸露Raw方法，同样会引发严重注入风险；同时提醒开发者警惕Scan、sql.NullString、日志打印等易被忽视的注入入口，强调安全关键在于执行前的参数绑定逻辑，而非结果处理或类型包装。

golang如何防止SQL注入_golang SQL注入防护解析

用 `database/sql` 的 `Query` 和 `Exec` 传参，别拼字符串

Go 里 SQL 注入的根源几乎全是手动拼接 SQL 字符串，比如 "SELECT * FROM users WHERE id = " + userID。只要用户控制 userID，就能塞进 1 OR 1=1 -- 这类 payload。

正确做法是把变量当参数传给 Query 或 Exec，让驱动自动处理转义和类型绑定：

rows, err := db.Query("SELECT name FROM users WHERE age > ?", age)

注意：不同驱动占位符不同——mysql 用 ?，postgres 用 $1，sqlite 两者都支持但推荐 ?。混用会导致 sql: expected 1 arguments, got 0 这类错误。

永远别用 fmt.Sprintf 或 + 拼 SQL
如果必须动态拼表名或字段名（如分表查询），只能白名单校验，不能靠参数化
Scan 不防注入，它只读结果；防护发生在执行前

警惕 `sql.RawBytes` 和 `sql.NullString` 的误用场景

这些类型本身不引发注入，但常出现在“以为安全了”的错觉里。比如有人把用户输入先塞进 sql.NullString，再拼进 SQL，以为加了包装就没事——其实没用，拼接时照样裸奔。

更隐蔽的是日志或调试中打印原始 SQL：log.Printf("executing: %s", query)，如果 query 是拼出来的，日志就成了注入入口（尤其配合远程日志系统时）。

sql.NullString 只解决空值映射问题，不参与 SQL 构建
所有日志里的 SQL 必须确认来自预编译语句，或已手动过滤/脱敏
用 db.QueryRow().Scan() 时，参数仍需走问号占位符，不是用了 Scan 就自动安全

预处理语句（`Prepare`）不是银弹，但能堵住某些边界漏洞

预处理在服务端提前编译 SQL 模板，客户端只传参数值，理论上杜绝语法层面的注入。但 Go 的 database/sql 默认开启连接池复用预处理语句，而某些驱动（如旧版 go-sql-driver/mysql）在连接断开后未自动重准备，可能触发 stmt is closed 错误。

实际建议：对高频、固定结构的查询（如登录校验、ID 查询）显式用 db.Prepare，但别为了“更安全”强行全量预处理——普通 Query 已足够防注入，预处理主要价值在性能。

预处理不能防止表名/列名/ORDER BY 子句的注入，这些仍需白名单
PostgreSQL 驱动默认强制预处理，MySQL 驱动需加 parseTime=true&loc=Local 等参数才稳定支持
短生命周期 HTTP handler 中，直接 db.Query 比反复 Prepare/Close 更轻量

ORM 如 `gorm` 或 `sqlc` 的坑比你想象的多

很多人以为 ORM 天然免疫 SQL 注入，结果栽在 Where("name = '" + name + "'") 或 Session().Select("id, " + userField) 这类写法上。GORM 的 Where 方法接受两种签名：Where("age > ?", 18) 安全，Where("age > " + str) 危险。

sqlc 因为生成的是纯 database/sql 代码，只要模板里没用 {{.arg}} 拼接，就基本安全；但它不拦着你在 Go 层自己拼 SQL。