graphql本身不执行sql，但resolver中若用字符串拼接用户输入构造原始sql（如raw()、text()、模板字面量），且未参数化传参，仍会导致sql注入；orm安全不等于绝对安全，关键在调用方式是否隔离用户输入。
GraphQL接口本身不直接执行SQL，但后端 resolver 中若用 ORM 拼接原始 SQL 或调用不安全的查询方法，仍可能触发 SQL 注入。关键不在 GraphQL 层，而在 resolver 调用 ORM 的方式是否引入用户输入到未参数化的 SQL 片段中。
resolver 中避免 raw SQL + 字符串拼接
很多开发者误以为用了 ORM 就绝对安全，结果在 resolver 里写 session.execute("SELECT * FROM users WHERE name = '" + args.name + "'") —— 这和直连 JDBC 写 statement.executeQuery("..."+input) 一样危险。
- 永远不要用
+或f-string把用户输入（args、info.variable_values）拼进 SQL 字符串 - ORM 的
raw()、execute()、text()等接口，必须搭配参数化传参，例如 SQLAlchemy 的session.execute(text("... :name"), {"name": args.name}) - 即使使用 QueryBuilder（如 TypeORM 的
createQueryBuilder()），也应优先走.where("u.name = :name", { name: args.name })，而非.where(`u.name = '${args.name}'`)
警惕 ORM 的“看似安全”但实则危险的操作
某些 ORM 方法表面封装了参数化逻辑，但在特定用法下会退化为字符串拼接。比如：
- TypeORM 的
find({ where: { name: args.name } })是安全的；但find({ where: "name = '" + args.name + "'" })就是高危的 - Django ORM 的
User.objects.filter(name=args.name)安全；而User.objects.extra(where=[f"name='{args.name}'"])不安全，且已弃用 - Prisma 的
prisma.user.findMany({ where: { name: args.name } })强制参数化，基本无注入风险；但若用prisma.$queryRaw，就必须手动确保参数绑定，不能用模板字面量插值
GraphQL 层该做的配合：字段白名单 + 输入校验
GraphQL 并不阻止你查 __schema 或嵌套 20 层，但它能帮你收口字段访问。这对防 SQL 注入虽不直接，却能减少攻击面：
- 禁用
__introspection在生产环境（尤其当 schema 暴露敏感字段名时） - 对 resolver 入参做基础校验：比如
id字段只接受^[a-zA-Z0-9_-]{1,48}$，拒绝' OR '1'='1类似值（注意：这不是替代参数化，而是多一层过滤） - 避免把整个
args对象透传给 ORM 查询构造器——明确指定要过滤的字段，而不是where: { ...args }无差别展开
别忽略数据库连接权限与 ORM 配置
即使代码层没出错，底层配置不当也会放大风险：
- 数据库账号仅授予必要表的
SELECT权限（如只读 API），禁用DROP、CREATE、UNION相关权限 - 禁用 ORM 的
allowExposingRawResults（NestJS GraphQL）、enableSchemaStitching（Apollo Server）等调试功能上线 - 确保 ORM 日志不打印完整 SQL（尤其含参数值），防止日志注入或敏感信息泄露
最易被忽略的一点：GraphQL resolver 返回的对象若包含动态计算字段（如 computedField: () => db.query(...)），这个内部调用链是否也被参数化保护？很多人只检查顶层 resolver，忘了嵌套的 service 方法里藏着 knex.raw()。
