代码审计里的 GraphQL 授权：六个检查点

生产环境开着内省，等于把完整 schema 与字段类型直接公开，降低探测成本

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

一个请求用别名可以并发上千次查询，限流必须按字段解析次数算，按请求数完全挡不住。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

授权要落在每个 resolver 上，漏掉一个字段就等于漏掉一个可读接口，字段级鉴权最常被遗漏。

检查点三：校验逻辑

查询深度与复杂度不设上限，嵌套几层的关联查询就能把数据库拖到超时，一个请求就够。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 生产环境开着内省，等于把完整 schema 与字段类型直接公开，降低探测成本

检查点四到六

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• GraphQL 把所有操作收敛到一个端点，网关按路径与请求数做的限流基本失效
• 从 REST 迁过来时，越权检查还按 URL 写，换了协议之后整体失效，要按字段重建一份授权矩阵
• 只在网关按请求数限流，别名批量一次就打穿
• 以为不暴露 schema 就安全，字段名在前端包里都能找到
• 鉴权写最外层，嵌套对象的字段没判归属

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。