SQL注入防护：输入验证应放在客户端还是服务端？

或许你会认为，在浏览器中通过 JavaScript 进行前端校验，就能有效防御 SQL 注入？事实并非如此。客户端验证仅能作为辅助手段，绝不能成为安全防线——真正的守门人，必须部署在服务端。

输入验证必须放在服务端，客户端验证只能作为辅助，不能作为安全防线。

为什么客户端验证无法阻止 SQL 注入

核心原因在于：浏览器端执行的 JavaScript 校验，在安全层面是不可信的。攻击者可以轻易禁用脚本，通过 curl 直接发送请求，修改前端代码，甚至抓包重放——所有这些操作，都不经过你的 JS 校验逻辑。换句话说，攻击者根本无需打开你的网页，就能将 ' OR 1=1 -- 这样的 payload 直接送达后端接口。

• 用户提交的任何数据，只要未经过服务端验证，就应视为“未验证”数据。
• HTML5 的 type="email" 或 pattern 属性、Vue 的表单验证规则、React 的 onChange 校验——这些都属于客户端行为，不具备安全约束力。
• 即使采用 WebAssembly 或加密校验，只要验证逻辑在浏览器端执行，就存在被逆向分析或绕过风险。

服务端验证应如何有效实施

服务端验证并非简单的“重复检查”，而是应作为“唯一可信的入口守门人”。它必须覆盖所有可能的输入来源：GET 查询参数、POST 表单、JSON 请求体、Cookie、HTTP 头（如 X-Forwarded-For），以及 gRPC 或 WebSocket 消息等。

• 优先采用白名单策略：例如用户名仅允许 [a-zA-Z0-9_]{3,20}，ID 强制转换为 int 类型。
• 对于格式不可预知的字段（如搜索关键词），至少应进行危险字符过滤或转义：'、"、;、--、/*、UNION、SELECT 等。但需注意，过滤不能替代参数化查询。
• 验证失败时，必须立即中断请求，返回通用错误（如 400 Bad Request），绝不能泄露具体字段名、校验规则或数据库结构信息。

常见错误：将验证逻辑混入 ORM 或框架默认行为

许多开发者错误地认为，使用 ORM（如 Django ORM、Sequelize、MyBatis）就能自动防御 SQL 注入——事实并非如此。ORM 的安全前提在于：不手动拼接 SQL 字符串。

• 在 MyBatis 中，使用 ${username} 属于字符串拼接，存在风险；而使用 #{username} 才是预编译方式，安全可靠。
• Django 的 filter(name__icontains=request.GET.get('q')) 是安全的，但如果在 raw() 或 extra() 中拼接字符串，则会直接破坏安全防线。
• SQLAlchemy 的 text() 如果直接插入用户输入，同样会遭受攻击；必须使用 bindparam 或 execute(..., {'val': user_input}) 进行参数化绑定。

真正容易被忽略的关键点在于：验证和参数化查询并非二选一，而是必须同时启用。验证负责提前拦截明显非法的输入（如负数 ID、超长邮箱），参数化查询则作为兜底机制，处理所有漏网之鱼。缺少任何一个环节，安全防护链就会断裂。