A recursive query repeatedly follows self-referencing relationships in a graph, such as users linking to friends who link to more friends. In GraphQL, recursion can become expensive very quickly if depth is not constrained. Without limits, the server may spend excessive CPU or memory resolving nested objects.
How Recursive Queries Work
Recursive queries are a pattern for traversing self-referencing data, where each result can feed the next step. In graph-oriented APIs, that makes them useful for hierarchies and relationship exploration, but it also means the query can keep expanding until a stopping condition is reached.
The core idea is simple: a recursive query does not just retrieve one layer of data, it repeatedly asks for the next layer. That makes the shape of the data as important as the data itself, because a deep or highly connected structure can multiply work very quickly.
For readers working with GraphQL, recursive querying is often tied to nested object resolution and relationship depth. The issue is not recursion by itself, but recursion without a practical bound. A system that allows unbounded traversal can turn a small-looking request into a large execution tree.
That is why recursive queries are usually discussed alongside depth limits, pagination, and query cost controls. Those mechanisms do not change what recursion is, they constrain how far it can go and how much server work it may consume.
Where Recursive Queries Become Expensive
The main cost driver is fan-out. If each node points to several more nodes, the number of lookups can grow geometrically rather than linearly. In a graph of users, teams, products, or permissions, a few levels of nesting can produce a very large result set even when the query itself looks compact.
Recursive evaluation also stresses memory and CPU because the server must keep track of traversal state, object resolution, and intermediate results. In practice, the expensive part is often not the final payload but the amount of work needed to discover it.
That cost can be amplified by repeated references, cycles, or highly connected records. Good recursive-query handling therefore depends on both data-shape awareness and execution controls that prevent accidental runaway traversal. OWASP API Security Top 10 is useful here because unrestricted resource consumption is a closely related API risk pattern.
Recursive queries are also sensitive to data quality. Poorly maintained self-references, duplicate edges, or missing termination logic can make the same traversal far more expensive than expected, even when no attacker is involved.
Security Implications of Recursive Query Depth
From a security perspective, the concern is resource exhaustion and abuse of trust in the query engine. A recursive request can be used to drive disproportionate CPU, memory, or backend fetch activity, which may slow the service for other users or push it toward denial of service conditions.
The same pattern can also expose more data than intended if traversal rules are too permissive. In graph-style systems, the answer to one node may reveal a path into additional objects, so the access model must match the traversal model. That is one reason API authorization and response-shaping controls matter around recursive operations. NIST SP 800-53 Rev 5 Security and Privacy Controls provides relevant control language for access control, auditing, and system integrity.
Recursive query risk is especially important in APIs that expose hierarchy or relationship data, because a single request can trigger large downstream work across multiple objects. In GraphQL-style systems, that makes depth and cost enforcement part of the security boundary, not just a performance optimisation. NIST Cybersecurity Framework 2.0 is a useful broader reference for governance, protection, detection, and recovery around this kind of exposure.
For implementation patterns that cross into API credential and authorization concerns, the practical challenge is to ensure that recursive traversal never becomes a bypass for intended access boundaries. The query shape should not be able to amplify a weak permission model into broad data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic Access Control | Recursive API traversal can be abused through tool-like query execution with excessive resource use. |
| Recommendation — Limit recursive traversal depth and cost to prevent query-driven resource exhaustion. | ||
| OWASP Non-Human Identity Top 10 | Non-Human Identity Top 10 | Recursive queries can amplify access paths and expose data across machine-driven API interactions. |
| Recommendation — Constrain recursive access paths and verify traversal authorization at each step. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Recursive query execution must preserve authorization boundaries while traversing nested data. |
| PR.PT — Protective Technology | Query-depth controls and cost ceilings are protective mechanisms against runaway recursion. | |
| Recommendation — Enforce traversal authorization so recursion cannot bypass intended access boundaries. Apply query-depth and complexity controls to cap recursive execution cost. | ||
| CIS Controls v8 | 6.3 — Data Recovery and Asset Recovery Procedures | Recursive query abuse can create availability impact that needs detection and response readiness. |
| Recommendation — Monitor recursive query load and prepare recovery steps for resource exhaustion incidents. | ||
Practitioner Guidance
What to watch for: Recursive queries deserve a hard look whenever the underlying data model can expand unpredictably or reference itself. The most common mistake is treating recursion as a purely functional feature and ignoring the execution cost until production traffic surfaces it.
Governance implication: Treat depth limits, cost ceilings, and traversal rules as policy decisions, not ad hoc tuning. If a query language allows recursion, ownership should be clear for who defines safe bounds, who reviews exceptional queries, and who monitors abuse patterns. For graph and API implementations, OWASP API Security Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce the need to control exposure, observe abnormal resource use, and recover quickly when limits are exceeded.
Practitioner takeaway: The safest recursive query is the one that can only expand as far as you have explicitly designed it to.
Risk and Threat Considerations
Recursive queries can create a denial-of-service style exposure when a small request expands into a disproportionately expensive traversal. They are also attractive to attackers because deep nesting and broad fan-out can consume backend resources without requiring obvious malformed input.
Failure mechanism: Unbounded recursion or weak depth controls allow repeated resolution of nested relationships, which can amplify CPU, memory, and database load. If access checks are applied inconsistently during traversal, recursion can also expose more objects than the caller should see.
Impact: The service may slow down, fail under load, or return unintended data paths, especially in graph-heavy APIs where one object leads to many more. In the worst case, recursive requests become an efficient abuse path for service degradation or broad data discovery.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
