如何在 Go 微服务中防范 SQL 注入与 XSS 攻击

在微服务开发中，防注入和防XSS算是基本功，但很多细节容易被忽略，一旦出错，后果往往很严重。这里有几个核心判断，值得先在心里放一放。

占位符写错，等于没防

很多人以为参数化查询就是加上 ? 或 $1 就完事了，但占位符的写法并不是通用的。MySQL 驱动只认 ?，如果你写成 $1，查询可能永远没结果，或者意外匹配到字段值恰好是 "$1" 的记录；而 PostgreSQL 驱动只认 $1、$2，写成 ? 的话，驱动要么直接报错 sql: expected 0 arguments, got 1，要么干脆静默地丢弃参数。这两种情况，都不会报错，但参数会被当字面量传入——这跟直接字符串拼接没有任何区别。

跨数据库迁移时，如果硬编码占位符，运行时行为就会突变。更稳妥的做法是封装一个统一的 QueryBuilder 抽象层，让它按驱动类型自动适配占位符。另外，千万别以为 ORM 就“默认安全”——比如 GORM 的 Raw()、Exec()、Session().Exec()，一旦调用，所有防护自动失效。

GORM 的原生SQL接口是逃生舱口，不是后门

Raw() 方法本身不危险，危险的是人们把它当成“可以放心拼接”的借口。只要用户输入进了 SQL 字符串字面量，就已经失守了。比如这种写法：db.Raw("SELECT * FROM users WHERE name = '" + name + "'").Find(&users)，就是典型的错误示范。正确的做法是 db.Where("name = ?", name).Find(&users)，或者 db.Raw("SELECT * FROM users WHERE name = ?", name).Find(&users)。

需要注意，动态表名、字段名、ORDER BY 子句无法参数化，必须用白名单校验，比如只允许 name、email、created_at 这几个字段。gosec 扫描规则 G201 会标记所有 Raw() 调用，需要人工逐条确认是否带参数化。另外，别以为加了 Where() 就安全——Where("id = ?", id).Raw("") 中的 Raw() 仍然独立承担风险。用 fmt.Sprintf 拼接 SQL 是高危红线，连测试代码里都该禁用。

html/template 只在HTML上下文里生效

html/template 对 {{.UserName}} 会自动转义成 ，但它只在 HTML 元素内容中生效。一旦变量进到 JS 字符串、href、src、style 或 innerHTML，它完全不起作用。比如这种写法：，输入 "); alert(1); // 就能直接逃逸执行。

安全写法是：，其中 UserNameJSON 是经过 json.Marshal 处理后的字符串。对于富文本内容，不能靠 template.HTML 直接放行，必须用 bluemonday 等白名单净化库，禁用 script、onerror、ja vascript: 等执行向量。此外，HTTP 响应头仍需设置 Content-Security-Policy: default-src 'self'，这是防止 inline script 执行的最后一道防线。

微服务间调用也不是信任区

内部服务通信常被误认为“可信”，但攻击者完全可以通过边界网关或上游服务污染数据流。一个未校验的 user_id 字段，可能从 API 网关透传到下游订单服务，再拼进日志 SQL 或渲染到管理后台页面。

每个微服务入口必须做输入验证，不能只靠网关层拦截。下游服务接收 JSON 或 gRPC 请求时，对关键字段（比如 order_id、redirect_url）要强制白名单或正则校验。跨服务传递的 HTML 片段（如通知模板）必须经 bluemonday 二次净化，不能复用上游已处理的结果。日志打印用户输入前，还需要过滤控制字符和双引号，避免日志注入伪造条目。

最麻烦的从来不是“会不会写参数化查询”，而是动态字段、多数据库兼容、服务间信任边界模糊这些点——它们不报错，但会在某个上线后的深夜突然触发漏洞。