SQL注入防护的开发安全评审，核心不是看有没有用参数化查询这一句话，而是看数据从入口到执行层之间，每一道拼接、每一次动态SQL、每一个存储过程调用是否都处于可控状态。多数评审失败的原因是把SQL注入当成单一漏洞来查，而不是当成数据流控制问题来审。评审清单要围绕“输入识别—语句构建—执行路径—错误回显—权限兜底”这五层来展开，任何一层出现裸奔，整个防护链条就失效。

第一项要核查的是动态SQL拼接点。开发人员常把参数化查询用在明显的查询条件上，却忽略排序字段、表名、列名、分页参数、分组字段这些无法直接绑定的位置。评审时搜索代码中的字符串拼接符号，尤其是在Java里的“+”连接SQL片段、PHP里的“.”连接变量、C#里的“$”字符串插值，以及Python里的f-string格式化。只要这些拼接片段最终进入SQL执行函数，就必须标记为高风险点。对于order by、group by、表名切换这类场景，正确做法是建立白名单映射，前端传入的标识符只能对应后端预定义的枚举值，绝不允许直接把用户输入拼进语句。

第二项是ORM框架的误用。很多人以为用了Hibernate、MyBatis、Entity Framework就天然防注入，实际上这些框架里同样存在原生SQL和动态SQL接口。MyBatis里的${}和#{}就是最典型的对比，#{}走预编译参数绑定，${}是直接字符串替换。评审时要重点检查XML映射文件中是否出现${}，如果出现，要确认变量来源是否经过白名单校验。Hibernate里的createQuery拼接字符串、JPA里的nativeQuery同样属于高危区域。ORM不能作为安全评审的豁免理由，只能作为查找范围的缩小依据。

第三项是存储过程的安全性。存储过程内部如果使用动态拼接然后执行，比如SQL Server里的sp_executesql配合拼接字符串、MySQL里的PREPARE语句使用拼接变量，同样存在注入风险。评审存储过程时不能只看调用层有没有传参，要打开存储过程定义，检查内部是否把入参拼接到SQL文本再执行。很多老系统把业务逻辑下沉到数据库层，存储过程里大量使用字符串拼接，这类问题比应用层注入更难发现，因为代码扫描工具往往覆盖不到数据库内部对象。

第四项是二次注入和编码绕过。有些系统在数据入库时做了转义或过滤，但数据出库后又被拼接到新的SQL语句中执行，这就是二次注入。评审时要追踪数据的完整生命周期：用户输入存入数据库后，后续哪些功能会读取该数据并用于构建SQL。比如用户昵称在注册时过滤了单引号，但后台管理页面读取昵称后拼接到查询语句，攻击者可以在昵称里存入经过编码的恶意内容，在二次使用时形成注入。防护重点不是入库时转义，而是所有SQL构建点都统一使用参数化，与数据来源无关。

第五项是错误信息泄露。生产环境的数据库报错信息如果直接返回给前端，等于给攻击者提供了SQL语法结构、表名、列名、数据库类型等关键情报。评审时要检查全局异常处理是否统一拦截数据库异常，对外只返回通用错误提示。同时要确认调试模式在生产配置中已关闭，框架自带的详细错误页面不会暴露堆栈信息。很多注入攻击的第一步就是通过报错回显来探测注入点，把错误信息收敛掉能显著提高攻击成本。

第六项是数据库权限最小化。应用连接数据库的账号不应具备sysadmin、root、sa这类超级权限，也不应拥有对系统表的读取权限。评审时查看连接字符串中使用的账号，确认其权限范围是否仅限于业务库的增删改查和必要的存储过程执行权限。即使注入发生，低权限账号也能限制攻击者读取其他库、写文件、执行系统命令的能力。同时要检查是否禁止了多语句执行，比如MySQL连接串中未关闭allowMultiQueries、SQL Server未限制批量语句，这些配置会放大注入的危害程度。

第七项是WAF和输入过滤的定位问题。输入过滤只能作为纵深防御的补充，不能作为主防护手段。评审时如果看到代码里大量使用正则替换单引号、关键字过滤、addslashes这类做法，要明确标记为防护不足。这些手段可以通过编码绕过、大小写变换、注释插入、双写绕过等方式突破。正确做法是输入过滤只用于业务规则校验，比如手机号必须是数字、邮箱必须符合格式，而SQL安全完全交给参数化查询。把安全责任放在过滤函数上，等于把防线建立在攻击者可绕过的沙地上。

第八项是批量操作和IN子句的处理。很多开发在遇到IN查询时，因为参数数量不固定，就选择把参数列表拼成逗号分隔的字符串直接塞进SQL。这是高频注入点。评审时要检查所有IN子句的构建方式，正确做法是动态生成占位符，比如传入三个参数就生成“IN (?, ?, ?)”，然后逐个绑定。MyBatis里用foreach标签生成占位符列表，JDBC里循环拼接问号，这些都是安全写法。直接拼接用户输入形成“IN (1,2,3)”的形式，即使输入看起来是数字，也要标记为风险点，因为攻击者可以构造闭合括号注入额外语句。

第九项是LIKE查询的转义。LIKE模糊查询中的通配符%和_本身不构成注入，但如果用户输入被拼接到LIKE模式中，攻击者可以构造恶意模式来探测数据。更严重的是，如果开发为了转义单引号而手动处理，容易遗漏LIKE特有的转义字符。评审时要确认LIKE查询使用参数绑定，同时根据业务需求决定是否转义通配符。如果业务要求用户输入的通配符只作为普通字符处理，需要在代码中显式转义%和_，并设置ESCAPE子句。这个问题常被忽略，但在数据量大的系统中可被用于资源消耗型攻击。

第十项是框架和中间件的版本与配置。某些数据库驱动或框架版本存在已知的SQL注入相关漏洞，评审时要核对依赖版本是否在安全范围内。比如旧版MySQL Connector/J在某些配置下对多字节字符处理不当，可能被用于绕过转义。同时检查数据库连接配置中是否开启了不必要的功能，比如MySQL的local_infile参数如果开启，注入成功后可以通过LOAD DATA LOCAL INFILE读取服务器文件。这类配置层面的问题不属于代码逻辑漏洞，但同样是SQL注入防护评审的必要组成部分。

第十一项是日志和监控的完备性。安全评审不仅要看预防措施，还要看发生注入后能否及时发现和追溯。检查应用是否记录了SQL执行日志，日志中是否包含完整的SQL语句和绑定参数。很多系统只记录业务操作日志，不记录底层SQL，一旦发生注入攻击，无法还原攻击路径和影响范围。同时要确认是否有异常SQL检测机制，比如对包含union select、sleep、benchmark、information_schema等特征的SQL语句进行告警。日志本身也要注意脱敏，不能把密码、令牌等敏感数据明文写入日志。

第十二项是代码评审的覆盖范围。SQL注入漏洞经常出现在边缘功能里：导出报表、数据导入、批量删除、搜索接口、API回调、定时任务、后台管理页面。这些模块往往不在主流程的测试范围内，开发人员也容易放松警惕。评审时要拉取完整的代码仓库扫描报告，确认所有执行SQL的代码路径都被覆盖，包括那些看起来不直接接收用户输入的内部调用。攻击者可以通过间接参数污染、接口参数猜测等方式触达这些隐藏路径。

第十三项是第三方组件和插件。很多系统集成了报表工具、数据可视化组件、低代码平台，这些组件内部可能自行拼接SQL。评审时如果发现使用了第三方SQL执行组件，要确认其版本和配置是否安全，是否允许用户自定义SQL片段。有些报表工具允许用户在前端配置数据源和查询条件，底层实现就是字符串拼接，这类组件必须限制在可信网络内使用，或者通过代理层做严格的参数校验。

第十四项是测试用例的有效性。安全评审不能只看代码，还要看已有的安全测试是否真正覆盖了注入场景。检查测试用例中是否包含典型的注入payload，比如单引号闭合、union查询、布尔盲注、时间盲注、堆叠查询、注释符截断等。很多团队的测试用例只覆盖了正常业务输入，对异常输入和恶意构造的输入没有验证。评审时要推动补充自动化安全测试用例，把注入检测集成到CI流水线中，每次代码提交都跑一遍基础注入向量集。

第十五项是修复方案的落地验证。评审发现SQL注入问题后，不能只停留在“建议使用参数化查询”的层面，要给出具体的修复代码示例，并验证修复后确实不存在拼接路径。对于无法参数化的场景，比如动态表名、动态列名，要给出白名单校验的实现方式。修复完成后需要回归测试，确认业务功能正常且注入向量无法突破。评审报告里要记录每个问题的位置、风险等级、修复方案、验证结果，形成闭环。

SQL注入防护的开发安全评审，本质上是对数据流控制能力的审计。参数化查询是基础，但不是全部。真正有效的防护需要开发规范、代码审查、框架约束、数据库配置、监控告警多管齐下。评审清单的价值在于把散落的知识点变成可执行的检查动作，让每一次评审都能系统性地覆盖所有风险面，而不是靠评审人员的个人经验随机发挥。