或许你会认为，在浏览器中通过 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、超长邮箱），参数化查询则作为兜底机制，处理所有漏网之鱼。缺少任何一个环节，安全防护链就会断裂。
