Swagger无法修复SQL注入漏洞，它仅生成接口文档和前端提示，不参与后端校验；真正防护必须依赖后端参数化查询，如PreparedStatement、占位符执行等。
直接用 Swagger 定义参数类型，完全不能修复 SQL 注入漏洞。它只影响文档生成和前端调用提示，对后端执行逻辑零防护。
Swagger 的 type 和 format 不参与后端校验
Swagger（OpenAPI）本质是接口契约描述，type: integer 或 format: email 仅用于生成文档、Mock 服务或前端表单校验。后端框架（如 Spring Boot、Express、FastAPI）默认不会自动根据 OpenAPI 定义拦截或转换请求参数。
常见错误现象：
- Swagger UI 显示
id是integer，但攻击者仍可发GET /users?id=1%20OR%201=1—— 后端若用字符串拼接，照样执行恶意 SQL - 定义了
pattern: "^[a-zA-Z0-9_]{3,20}$"，但没在控制器里调用正则验证，该 pattern 就只是文档里的装饰
真正起作用的必须是后端代码层的参数化查询
修复核心只有一条：所有数据库操作必须使用预编译语句（PreparedStatement、query with placeholders、ORM 的参数化方法），而非字符串拼接。
实操建议：
- Java + JDBC：强制替换所有
Statement.execute(sql + userParam)为PreparedStatement，占位符统一用? - Python + psycopg2：用
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))，绝不用f"WHERE id = {user_id}" - Node.js + pg：用
client.query("SELECT * FROM users WHERE name = $1", [name])，不拼接`WHERE name = '${name}'` - Spring Data JPA：优先用
@Query(value = "... WHERE name = :name", nativeQuery = true)+@Param("name")，避免findByName(String name)被误用于动态构造语句
Swagger 可配合做的辅助加固点
它虽不能防注入，但能帮你暴露风险点、推动规范落地：
- 在
parameters中显式标注required: true和schema.type，倒逼开发补全后端类型校验逻辑 - 用
example和description写明“该字段将传入 SQL 查询，请确保已参数化处理”，作为团队协作提醒 - 结合 API 网关（如 Kong、Apigee）开启基础 WAF 规则，拦截含
UNION SELECT、sleep(的请求 —— 但这只是兜底，不能替代参数化
最容易被忽略的是：Swagger 文件更新了，但对应 controller 方法里的 SQL 还是字符串拼接的老写法。修复必须落在代码执行路径上，而不是文档里。
