SQL注入未被拦截主因是预处理误用：仅数据库驱动占位符和ORM明确绑定参数有效，其余字符串拼接均不安全；须严格最小权限、白名单校验ORDER BY字段、分层加密敏感字段、动态获取密钥、构建流程嵌入SQL安全检查。
SQL注入没被拦截，大概率是预处理没用对
很多团队加了WAF、开了参数化查询，还是被扫出SQL注入——问题常出在「用了预处理语法，但拼接发生在数据库驱动之外」。比如用fmt.Sprintf拼接SQL模板再传给db.Query，或者把用户输入塞进ORDER BY字段名里却没白名单校验。
真正起作用的只有两类操作：数据库驱动原生支持的占位符（如?$1、?、:name），以及ORM明确标记为「绑定参数」的调用（如sqlx.Named、gorm.Where("id = ?", id)）。其余任何字符串拼接，无论多“干净”，都等于裸奔。
- 检查所有
db.Query/db.Exec调用，确认参数全是独立变量，没混在SQL字符串里 -
ORDER BY和GROUP BY字段名不能参数化，必须用白名单匹配：if !validSortField(userInput) { return error } - PostgreSQL的
jsonb路径表达式（如$1 #> '{a,b}'）中，$1可参数化，但{a,b}不可，需提前校验结构
应用层权限控制失效，因为DBA给了too much privilege
开发习惯性申请SELECT/INSERT/UPDATE/DELETE全库权限，结果一个SQL注入就能拖走用户表+订单表+密钥表。实际只需按模块最小授权：用户服务只读users、profiles，写user_sessions；支付服务只读orders、写transactions。
更关键的是隔离连接池：不同业务模块用不同DB账号，连到同一实例也不怕越权。否则一个模块的漏洞会直接污染整个数据平面。
- 用
CREATE ROLE app_user WITH LOGIN PASSWORD 'xxx'建专用账号，而非复用postgres或root - 权限只授给具体表：
GRANT SELECT ON TABLE users TO app_user，别用GRANT ALL ON DATABASE - Golang里用
sql.Open("postgres", "user=app_user ...")硬编码账号，避免环境变量泄露主账号
敏感字段加密后仍可被排序/模糊查询，说明选错了加密方式
用AES_ENCRYPT()或pgcrypto的encrypt()加密手机号，结果业务要按号段查用户、要LIKE搜索——这类需求注定和强加密冲突。确定性加密（如pgp_sym_encrypt()带固定salt）能支持等值查询，但无法支持范围或模糊匹配；而哈希（如sha256）虽快，但无法反解，连客服人工核验都做不到。
真正可行的折中方案是分层处理：展示层用脱敏（CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))），搜索层用单独的可逆索引字段（如phone_hash存SHA256(phone + salt)），且该字段不参与业务逻辑计算。
- 禁止在
WHERE里对加密字段用LIKE或>，MySQL的AES_DECRYPT()在WHERE中会导致全表扫描 - 如果必须模糊查，改用
pg_trgm扩展对明文副本建GIN索引，但该副本需严格隔离（如独立schema+只读账号） - 密钥管理别存在配置文件里，用
aws kms decrypt --ciphertext-blob或hashicorp vault read动态获取
CI/CD流水线里漏掉SQL安全卡点，上线即高危
代码里写了db.Query(fmt.Sprintf("SELECT * FROM %s", table))，但静态扫描工具没报——因为工具只认常见危险函数名，不分析字符串拼接上下文。真正的防线得嵌在构建流程里：PR提交时自动提取所有SQL语句，用正则筛出含%s、+、fmt.Sprintf的调用，再人工复核。
比扫描更重要的是运行时验证：在测试环境开启PostgreSQL的log_min_duration_statement = 0，捕获所有慢查询和异常查询模式，结合pg_stat_statements看是否有未参数化的高频SQL。
- Git钩子里加检查：
git diff --cached | grep -E '\.Query\(.*\+|fmt\.Sprintf' && echo "SQL拼接风险" && exit 1 - Docker Compose测试环境启用
log_statement = 'all'，日志送grep -E 'SELECT.*\+|WHERE.*user_input'告警 - 不要依赖「开发自测没发现问题」，SQL注入的触发条件往往藏在边缘路径（如导出Excel的
export?sort=created_at%20desc）
最麻烦的从来不是写对一条db.Query，而是让每个新来的同学在改三年前的报表代码时，依然不会手滑拼接字符串——这需要权限、工具、流程三者咬死，缺一不可。
