小程序对接网站接口时，SQL注入风险往往被低估。很多人以为小程序端只是发起请求，安全防护主要靠后端，但实际上小程序与网站之间的数据传输链路、参数拼接方式、接口设计逻辑都会直接影响注入攻击的成功率。小程序本身无法直接操作数据库，但攻击者根本不需要通过小程序界面，只要抓取到接口地址和请求参数，就能用脚本或工具直接对网站接口发起注入测试。因此，小程序对接网站时，防SQL注入的配置必须从接口层、参数层、数据库访问层同时下手，而不是只靠某一层做过滤。
最直接有效的做法是强制参数化查询。无论小程序端传过来的是用户输入、页面参数还是本地缓存里的值，后端接收到之后一律不能直接拼进SQL语句。以PHP的PDO为例，正确的写法是使用预处理语句，把参数绑定到占位符上，数据库驱动会自动处理转义和类型边界。比如：
$stmt = $pdo->prepare("SELECT * FROM users WHERE openid = :openid AND status = 1");
$stmt->bindParam(':openid', $openid, PDO::PARAM_STR);
$stmt->execute();
这种写法下，即使openid参数里包含单引号、分号或者注释符，也只会被当作普通字符串处理，不会改变SQL语句结构。很多开发者习惯用mysqli的real_escape_string手动转义，但这种方法依赖开发者记得对每一个变量都处理，一旦漏掉一个就前功尽弃。参数化查询则是从机制上杜绝拼接，属于最可靠的防线。
其次，小程序接口必须做严格的输入校验。参数化查询解决的是SQL结构不被篡改，但无法防止攻击者传入超长字符串、异常类型或者恶意载荷消耗数据库资源。例如一个本该是数字的id参数，如果攻击者传入“1 OR 1=1”，参数化查询虽然不会执行注入，但业务逻辑可能因为类型错误而出现异常。后端应该在接收参数后立即做类型判断和格式校验，数字类型用intval或filter_var强制转换，字符串类型限制长度和字符集，手机号、邮箱等固定格式用正则表达式验证。不符合规则的请求直接返回错误码，不进入数据库查询环节。
小程序端的请求头也需要配置好Content-Type和字符编码。很多SQL注入攻击会利用特殊编码绕过WAF或后端过滤，比如双重URL编码、Unicode编码、十六进制编码等。后端在读取参数前，应统一对请求体做一次标准化处理，拒绝非预期编码的请求。对于小程序常用的JSON格式接口，可以在框架层配置JSON解析器只接受UTF-8编码，并且限制请求体大小，防止超大payload拖慢服务。
数据库账号权限隔离是很多人忽略的一环。小程序对接的网站数据库账号，不应该使用root或者拥有全部权限的账号。按照最小权限原则，为小程序接口单独创建一个数据库用户，只授予SELECT、INSERT、UPDATE、DELETE等必要权限，不授予DROP、ALTER、CREATE等结构变更权限。这样即使某个接口被注入成功，攻击者也无法通过注入语句删表、改表或者提权。对于敏感数据表，还可以进一步做列级权限控制，比如用户密码字段只允许特定的存储过程访问，普通查询账号无法直接读取。
在SQL语句层面，还可以增加一层防御性写法。比如在查询条件中显式限制返回行数，使用LIMIT 1或者TOP 1，防止攻击者通过注入构造出全表扫描的语句。对于排序字段和排序方向这类经常需要动态拼接的参数，不要直接接收用户传入的字段名，而是使用白名单映射。例如前端传sort=time，后端映射为ORDER BY create_time；前端传sort=price，后端映射为ORDER BY price。任何不在白名单内的值都使用默认排序，从根源上避免ORDER BY注入。
网站服务器层面的WAF规则也要针对小程序接口做专门配置。很多通用WAF规则主要针对浏览器请求，对小程序常见的JSON格式请求体识别不够精准。可以在WAF中配置针对JSON参数值的SQL注入检测规则，拦截包含union select、sleep、benchmark、information_schema等关键词的请求。同时开启请求频率限制，对短时间内大量请求同一接口的IP进行封禁，因为自动化SQL注入工具通常会快速发送大量测试payload。频率限制可以设置在Nginx层或者应用层，比如同一IP每秒请求同一接口超过10次就返回429状态码。
日志记录和监控是发现SQL注入尝试的重要手段。小程序接口的访问日志应该记录完整的请求参数、响应状态码和处理耗时。当某个参数反复出现异常值或者请求耗时突然增加时，安全人员可以快速定位到攻击来源。对于生产环境，建议开启数据库慢查询日志，并设置合理的阈值。SQL注入攻击中的sleep函数和大量子查询往往会导致查询时间异常，慢查询日志能帮助发现这些异常语句。同时可以配置告警规则，当某个接口的错误率或平均响应时间超过基线时自动通知运维人员。
如果小程序对接的是已有网站系统，还需要检查历史代码中是否存在遗留的不安全写法。很多老系统在后台管理页面使用了拼接SQL，虽然小程序不直接访问后台，但攻击者可以通过小程序接口间接探测到后台接口地址，然后对后台发起注入。因此安全配置不能只覆盖小程序直接调用的那几个接口，整个网站系统的所有对外接口都应该纳入防护范围。建议做一次全面的代码审计，重点排查字符串拼接SQL、动态表名、动态列名等高风险写法。
对于使用ORM框架的项目，不能因为用了ORM就认为绝对安全。ORM只能防止普通的参数拼接注入，但如果代码中使用了原生SQL或者动态查询构造器，仍然存在注入风险。比如在ThinkPHP中使用Db::query()直接执行拼接字符串，或者在Laravel中使用DB::raw()传入用户输入，这些写法都会绕过ORM的自动参数绑定。正确的做法是尽量使用ORM提供的查询构造器方法，这些方法内部会自动做参数绑定。如果必须使用原生SQL，也要用绑定参数的方式传入变量。
小程序端的代码安全同样不能忽视。虽然小程序代码经过压缩和混淆，但攻击者仍然可以通过反编译获取接口地址和参数结构。因此不要把数据库表名、字段名、SQL语句片段等敏感信息写在小程序代码里。接口设计上避免使用自增ID作为唯一标识，改用UUID或者加密后的随机字符串，这样可以增加攻击者遍历数据的难度。对于需要登录的接口，确保session或token的校验在参数校验之前执行，未认证请求直接拒绝，不进入业务逻辑和数据库查询。
还有一个容易被忽略的细节是错误信息泄露。当SQL语句执行出错时，如果后端把数据库错误信息直接返回给小程序端，攻击者就能根据报错内容推断出表结构、字段名甚至部分数据。生产环境必须关闭详细的错误输出，统一返回模糊的错误提示，比如“系统繁忙，请稍后再试”。详细的错误信息只记录在服务器日志中，供开发人员排查问题使用。可以在框架配置中设置display_errors为false，同时开启log_errors为true。
对于高安全要求的场景，可以考虑在数据库前面增加一层SQL防火墙组件。这类组件可以实时分析SQL语句的语法结构和执行计划，拦截不符合预期的查询模式。例如某些数据库代理工具支持配置SQL白名单，只有预定义的查询模板才能执行，其他任何动态生成的SQL都会被拒绝。这种方式虽然配置成本较高，但能有效防御未知的注入手法，适合金融、政务等对数据安全要求严格的小程序应用。
最后要强调的是，防SQL注入不是一次性的配置工作，而是一个持续的过程。新的注入手法不断出现，业务代码也在不断迭代，任何一次功能更新都可能引入新的风险点。建议将SQL注入检测纳入上线前的安全测试流程，使用自动化扫描工具结合人工渗透测试，对小程序接口做全面的注入测试。同时定期检查数据库日志和WAF拦截记录，分析是否有新的攻击模式出现，及时更新防护规则。
