如何防止类GraphQL JSON API遭递归查询引发请求爆炸？

自动通用实现模式 #

目前有两种可自动实现的通用思路，无需频繁手动调整规则：

1. 类型循环检测 #

在解析查询时，实时跟踪当前查询路径中的对象类型。一旦检测到路径中重复出现同一类型（比如user → posts → comments → user，回到了已访问过的user类型），就自动终止该分支的递归展开。这种方式依赖API的类型元数据（比如每个字段对应的返回类型），能自动识别所有循环引用场景，无需人工配置嵌套规则。

2. 动态查询成本管控 #

不为查询设置固定深度阈值，而是为每个字段（尤其是关联字段）预设查询成本权重：比如获取单个用户成本为1，获取一篇帖子成本为2，加载一条评论成本为1，批量获取列表则按预计条数加权。解析查询时计算总成本，超过预设阈值就直接拒绝执行。这种方式比固定深度更灵活，既能阻止深嵌套递归，也能拦截浅层级但数据量极大的恶意查询（比如一次性请求1000篇帖子，每篇带100条评论）。

生产环境常用落地措施 #

如果自动模式无法完全覆盖业务需求，生产环境通常采用组合方案来平衡安全与灵活性：

• 固定深度+成本控制双重防线：以7-10层的固定深度限制作为基础安全门槛，同时叠加动态成本计算，应对深度不高但单层级数据量过大的场景。
• 角色分级限制：针对不同用户角色设置差异化的深度/成本阈值，比如管理员可使用更高阈值，普通用户则收紧限制；对敏感关联字段默认禁止嵌套，需特殊权限才能开启。
• 查询性能优化兜底：通过批量数据加载（类似GraphQL的DataLoader机制）、查询结果缓存等方式，降低合法复杂查询的数据库压力，同时减少恶意查询带来的资源消耗。
• 异常监控与告警：实时监控查询的深度、成本、执行时长，对接近阈值的异常查询触发告警，及时调整规则或拦截恶意请求。

另外，手动定义嵌套规则可作为特殊场景的补充：比如某些业务场景下明确禁止特定关联（如禁止从评论反向查询用户的帖子），可单独配置该规则，无需全局频繁调整。

内容的提问来源于stack exchange，提问作者Lance Pollard