SQL注入的本质是攻击者把恶意SQL片段混入应用构造的查询语句中，让数据库误把数据当作代码执行。比如登录表单里的用户名被拼进SELECT语句，如果应用没有做任何处理，攻击者输入 admin' OR '1'='1 就能绕过口令验证。这个问题存在了很多年，但至今仍能在大量Web应用中找到实例。真正有效的防护不能只靠某一层，因为数据从浏览器输入到数据库执行，中间跨越多层处理，每一层都有自己能看到和不能看到的上下文。前端知道用户输入的格式约束，却无法阻止绕过；后端掌握数据库交互，但未必能提前识别所有恶意模式；输出侧能处理已被存储的内容，却往往被忽视。前后端协同和双重屏障的思路，就是把防御拆成多个独立环节，让攻击者即使突破一层也难以为所欲为，而不是指望某一处过滤函数包打天下。
一、SQL注入的根源：数据与代码的边界被打破
SQL注入之所以危险，是因为开发者在构造查询时经常用字符串拼接把用户输入直接嵌入SQL语句。以Java JDBC为例，下面这段代码就存在典型漏洞：
String username = request.getParameter("username");
String password = request.getParameter("password");
String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);
这段代码里，username 和 password 被当成字符串与SQL语句拼接。攻击者只要在用户名处输入 admin' -- ，前半部分闭合单引号，后半部分注释掉剩余条件，就能让数据库执行 SELECT * FROM users WHERE username = 'admin' --' AND password = ''。此时口令检查完全被绕过。这种攻击不需要高深技巧，却能造成数据泄露、篡改甚至整表删除。
从原理上讲，问题是程序没有在数据与代码之间建立清晰边界。SQL解析器看到的是最终拼接后的字符串，它无法知道哪些部分是开发者写死的代码，哪些部分来自用户。只要攻击者能影响语句结构，就能改变查询语义。参数化查询之所以能根除大多数注入，正是因为它把用户输入作为参数单独传递，数据库在执行前就确定好语句结构，参数内容永远不会被当作SQL关键字解析。
但现实中的查询并不总是简单的条件拼接。动态排序字段、动态表名、IN列表、存储过程调用等场景难以直接使用占位符，这时就需要输入校验来控制允许的取值。输入校验和输出编码不能替代参数化查询，却能处理参数化覆盖不到的部分，并在其他环节继续加固。
二、前端输入校验：提升体验，但不能作为安全屏障
前端校验的价值常被误解。它的确能挡住一部分普通用户的无意输入，比如把手机号填成字母，或者在邮箱栏漏掉 @ 符号。通过HTML5的pattern属性、JavaScript正则或框架自带的表单验证，可以在请求发出前给出即时提示。下面是一个简单的前端校验示例：
function validateUsername(input) {
const pattern = /^[a-zA-Z0-9_]{3,20}$/;
if (!pattern.test(input)) {
return "用户名只能包含字母、数字和下划线，长度为3到20位";
}
return null;
}
document.getElementById("loginForm").addEventListener("submit", function(e) {
const username = document.getElementById("username").value;
const error = validateUsername(username);
if (error) {
e.preventDefault();
alert(error);
}
});
这段代码把用户名限制在字母、数字和下划线范围内，长度也做了约束。对正常用户来说，它能避免提交无效数据；对攻击者来说，这种限制在浏览器里很容易被绕过。攻击者可以禁用JavaScript，直接用curl或Burp Suite构造HTTP请求，把任何内容发送给后端。因此前端校验只能减少后端处理垃圾请求的压力，不能阻止有意的恶意输入。
更重要的是，前端校验规则和后端校验规则经常不一致。有些团队只在页面里写了正则，后端却直接信任前端传来的数据。一旦接口被单独调用，就完全失去保护。安全设计上有一条基本原则：所有客户端数据都不可信。前端可以做的事情是帮助用户快速发现错误、减少往返，但真正的准入判断必须由服务端完成。
不过前端也不是毫无安全价值。除了体验外，前端可以实时提示格式错误，降低服务器日志噪音；还可以配合CSP、输入长度限制等机制增加一定攻击成本。只是这些措施都只能当作纵深防御的辅助层，绝不能作为唯一防线。
三、后端输入校验与参数化查询：第一道真正防线
服务端接收所有请求，是执行SQL前最后一道可以阻止恶意数据入库的关口。后端输入校验应该采用白名单策略，而不是黑名单。所谓白名单，就是只允许符合预期的字符或格式通过，其余一律拒绝。比如用户名只允许字母、数字和下划线，排序字段只允许在固定集合中选择，ID必须是正整数。下面是一个Java后端的校验示例：
public String validateUsername(String username) {
if (username == null || !username.matches("^[a-zA-Z0-9_]{3,20}$")) {
throw new IllegalArgumentException("用户名格式不合法");
}
return username;
}
public String getOrderBy(String orderBy) {
Set<String> allowed = Set.of("id", "username", "create_time");
if (!allowed.contains(orderBy)) {
throw new IllegalArgumentException("非法的排序字段");
}
return orderBy;
}
这里的正则和允许集合就是白名单。注意，黑名单过滤通常不可靠，因为攻击者可以通过编码、大小写变换、注释插入等手段绕过。例如把 SELECT 写成 SeLeCt 或 SEL/**/ECT，黑名单就可能漏掉。白名单从需求出发定义合法输入，攻击者无法通过变形绕过，因为变形后的内容根本不在允许范围内。
参数化查询是更彻底的方案。它要求SQL语句的结构在执行前固定，用户输入只作为绑定参数传入。以Java的PreparedStatement为例：
String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement ps = connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs = ps.executeQuery();
在这种写法中，问号是占位符，数据库驱动会把参数值单独发送并转义，不会将其作为SQL语法解析。即使用户名是 admin' OR '1'='1，它也只会被当作字符串值去比较，无法改变查询结构。对于需要动态拼接的排序字段或表名，则应结合白名单校验，或者使用数据库提供的安全API，而不能直接拼接到语句里。
后端校验与参数化查询并不冲突。参数化解决的是语句结构注入，校验解决的是业务逻辑上的非法值，两者配合能覆盖绝大多数SQL注入场景。还应该注意，错误信息不要直接把SQL异常抛给前端，否则会泄露表结构等敏感信息。可以记录详细日志，但给客户端返回统一的错误提示。
四、输出编码：容易被忽略的第二道屏障
很多人认为SQL注入防护到参数化查询就结束了，但存储型攻击和二次注入往往在输出阶段才真正爆发。输出编码的核心思想是，当应用从数据库读取数据并输出到不同上下文时，按照目标格式对数据进行转义，防止数据被解释为代码。比如从数据库读取的用户昵称如果包含 <script> 标签，在输出到HTML页面时必须把 < 转义为 <，否则就会形成存储型XSS。这和SQL注入有什么关系？关系在于攻击链常常是组合的：攻击者可能先利用弱输入校验把一段恶意脚本写入数据库，后续管理员在后台查看数据时触发XSS，再利用管理员会话进一步攻击数据库。
在SQL注入的语境下，输出编码还能处理数据库中已经存在的恶意内容。例如某个早期版本漏洞允许恶意数据入库，修复注入后旧数据可能仍然存在。如果输出侧没有编码，这些内容会在页面上执行，导致二次伤害。以Java的JSTL或Thymeleaf为例，它们默认对输出进行HTML转义。下面是一个输出编码的示例：
String nickname = rs.getString("nickname");
// 输出到HTML上下文时进行转义
String safeNickname = HtmlUtils.htmlEscape(nickname);
这里的 HtmlUtils.htmlEscape 会把 < 转成 <，把 > 转成 >，这样浏览器就不会把用户数据当作HTML标签解析。如果输出目标是JavaScript、URL、CSS等其他上下文，还需要使用对应的编码函数，比如JavaScript转义、URL编码等。不同上下文的规则不同，用错编码函数仍然可能出问题。
输出编码之所以被称为第二道屏障，是因为它不依赖输入侧是否完美拦截。即使有恶意内容进入数据库，只要输出时做了正确转义，攻击就无法在浏览器端生效。对于SQL注入而言，输出编码不能阻止数据在数据库内部被当作SQL执行，但它可以阻断攻击者在获得数据后进一步利用展示环节扩大战果。把输入校验与输出编码配合起来，就是在数据流入和流出两个方向都设置检查点，形成纵深防御。
五、前后端协同的落地实践
要在项目中建立这种双重屏障，需要把职责划分清楚。前端负责格式预检和即时反馈，但不承担安全决策；后端负责强制校验、参数化查询和权限控制；输出层统一使用模板引擎的自动转义或显式编码函数。一个常见的设计是：前端表单提交前先做格式检查，通过后发送请求；后端Controller层先做DTO校验，Service层使用参数化查询或白名单处理动态SQL；数据返回给前端时，由模板引擎或序列化组件进行编码。
在团队协作中，还要避免只在前端写校验规则。可以制定接口规范，前端校验规则可以由后端接口文档生成，保证两边规则一致。后端校验失败时返回明确的错误码，前端根据错误码提示用户。监控和日志也要跟上：记录所有被后端校验拒绝的请求，分析是否存在集中攻击。对于特别敏感的操作，可以加入验证码、频率限制、IP黑名单等机制增加攻击成本。
最后用一个Go语言的例子展示后端参数化查询和输出编码的配合。假设使用database/sql和html/template：
import (
"database/sql"
"html/template"
"net/http"
)
func loginHandler(db *sql.DB, w http.ResponseWriter, r *http.Request) {
username := r.FormValue("username")
password := r.FormValue("password")
// 参数化查询
var id int
err := db.QueryRow(
"SELECT id FROM users WHERE username = $1 AND password = $2",
username, password,
).Scan(&id)
if err != nil {
http.Error(w, "用户名或密码错误", http.StatusUnauthorized)
return
}
// 输出编码：Go的html/template默认对变量进行HTML转义
tmpl := template.Must(template.New("welcome").Parse("欢迎，{{.Username}}"))
tmpl.Execute(w, map[string]string{"Username": username})
}
这段代码中，数据库查询使用了占位符 $1 和 $2，用户输入不会改变SQL结构。输出时使用 html/template 的默认转义，确保 username 中的特殊字符不会被浏览器当作HTML执行。前端则可以在这个接口基础上增加格式提示，但真正的安全由后端和输出层保证。只有把前端校验、后端参数化、输出编码三个环节串起来，才能对SQL注入形成完整的前后协同防线，而不是寄希望于某一层单独挡住所有攻击。