防御SQL注入需屏蔽数据库异常信息、强制参数化查询、遵循最小权限原则、实施前后端双重校验。统一错误响应、记录完整日志、禁用动态拼接、限制账户权限、字段级控制、配合WAF及结构化入参验证。
直接暴露数据库异常信息是SQL注入等攻击得以得逞的关键推手之一。攻击者通过错误响应中的表名、字段名、数据库类型甚至堆栈路径，能快速摸清后端结构，为构造精准注入语句提供依据。防御的核心不是“不让错误发生”，而是“不让错误说话”。
屏蔽敏感错误详情，统一返回格式
所有数据库异常（如MySQL 1064语法错误、PostgreSQL 42601语法错误）必须在服务端拦截，绝不透出原始错误消息给客户端。
- 使用中间件或全局异常处理器捕获数据库层抛出的异常，替换为通用提示，例如：“请求处理失败，请稍后重试”
- 日志中完整记录原始错误（含时间、请求ID、SQL语句片段、堆栈），但仅限内部审计使用
- 避免在HTTP响应体、响应头（如X-Debug-Info）、或状态码中隐含数据库类型（如用500泛化，不返回503 PostgreSQL-specific）
禁止动态拼接SQL，强制参数化查询
异常暴露只是表象，根源在于未隔离代码逻辑与用户输入。参数化查询让数据库引擎天然区分“结构”和“数据”，从根本上阻断注入可能。
- 所有WHERE、ORDER BY、LIMIT后的值必须通过预编译占位符（如
?、$1、:id）传入，禁用字符串格式化（fmt.Sprintf、+拼接） - 若需动态列名或表名（极少数场景），须严格限定白名单，并通过配置或枚举映射，不可来自任意请求参数
- ORM框架（如GORM、SQLAlchemy）默认支持参数化，启用
PrepareStmt=true等安全选项
最小权限原则 + 数据库层防护
即使API存在疏漏，受限的数据库账户也能大幅压缩攻击面。
- 为API服务单独创建数据库用户，仅授予
SELECT/INSERT/UPDATE必要表的权限，禁用DROP、CREATE、EXECUTE等高危操作 - 对读写接口做字段级控制：例如用户查询接口只允许查
name、avatar，不开放password_hash或api_token - 配合WAF规则（如ModSecurity）拦截含
UNION SELECT、OR 1=1、@@version等典型注入特征的请求
前端不信任 + 后端强校验双保险
前端限制（如输入框禁用单引号）纯属心理安慰，后端才是唯一可信防线。
- 对所有API入参做类型+范围+格式三重校验：ID必须为正整数、手机号匹配
^1[3-9]\d{9}$、邮箱用标准RFC验证 - 使用结构化验证工具（如Pydantic、go-swagger schema、JSON Schema）在路由入口处完成校验，非法请求直接拒收（HTTP 400）
- 对富文本、搜索关键词等难校验字段，采用上下文感知的转义（如SQL参数绑定）而非简单过滤或替换
