验证码和请求频率限制无法防止SQL注入，因其仅干扰自动化探测，而SQL注入本质是服务端代码漏洞；真正有效的防护必须依赖参数化查询、输入白名单验证及数据库最小权限控制。
验证码和请求频率限制本身不能防止 SQL 注入，它们只能干扰自动化探测行为——真正防注入的必须是参数化查询。如果你只加了验证码却还在用 username + "' OR '1'='1" 拼接 SQL，攻击者手动绕过验证码后照样能打穿数据库。
为什么验证码对 SQL 注入防护作用有限
SQL 注入本质是服务端代码漏洞，不是登录入口或表单交互问题。验证码拦得住爬虫发的 1000 次试探请求，但拦不住：
- 攻击者手工构造一次恶意请求（比如在 Burp Suite 里改一个 id=1' AND SLEEP(5)--）
- 利用已登录会话发起的注入（如修改 Cookie 中的 user_id 参数）
- 从 API 接口、GraphQL 查询、甚至 HTTP 头（如 X-Forwarded-For 被拼进日志 SQL）发起的注入
验证码只覆盖了“表单提交”这一种路径，而注入点远不止于此。
请求频率限制该设在哪一层才有效
单纯在 Nginx 或网关层限速（如 limit_req）容易被绕过，也容易误伤正常用户。真正起作用的位置是：
- 在 Web 应用框架的中间件中，针对具体路由做粒度控制（例如只对 /api/login 和 /search 限流，不对静态资源限）
- 结合用户身份标识（如 session ID 或 JWT payload 中的 sub），而不是只按 IP；否则内网用户或 NAT 后的用户会被连坐
- 限制的是“带可疑 payload 的请求”，比如检测到 URL 中含 UNION SELECT、OR 1=1、@@version 等关键词时触发更严策略，而非一刀切封 IP
注意：rate limiting 本身不解析 SQL，它只是增加攻击成本，不能替代输入处理逻辑。
真正该优先做的三件事
别把防御重心放在外围干扰上。以下操作必须完成，否则加再多验证码也没意义：
- 所有数据库查询强制使用参数化语句：cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))，绝不用 "WHERE id = " + str(user_id)
- 对所有外部输入（URL query、POST body、Cookie、Header）统一走白名单验证，比如 user_id 必须是正整数，直接 int() 转换并捕获异常，不依赖正则“过滤”
- 数据库连接账号仅授予最小权限：GRANT SELECT ON reports.* TO 'webapp'@'localhost'，禁止 DROP、INSERT、EXECUTE 等高危权限
这些措施失效时，再补验证码和限流才有实际价值。
最常被忽略的一点：ORM 框架里调用 .execute() 或 text() 执行原生 SQL 时，一样会注入。哪怕用了 Django 或 SQLAlchemy，只要写了 session.execute("SELECT * FROM users WHERE name = '" + name + "'")，前面所有防护就归零。
