Summary
GraphQLSecurityTestCase's query-depth/complexity check sends a hardcoded deeply-nested probe query using placeholder field names (a, b, c, ... j). Any real GraphQL schema rejects this at schema-validation time (HTTP 400, "Cannot query field ...") before the query is ever executed — so the depth-limit test can never observe whether depth limiting is actually enforced. As implemented, this check is dead code against real targets.
Location
src/main/java/org/owasp/astf/testcases/GraphQLSecurityTestCase.java (deep-query constant / testQueryDepthAttack-style method)
Reproduction
Scanned DVGA (/graphql) with ASTF v1.0.0. Introspection and batch-query-abuse were correctly detected, but no depth-limit finding was ever produced. Replaying the exact probe payload by hand against DVGA:
$ curl -s -X POST http://127.0.0.1:5000/graphql -H "Content-Type: application/json" \
-d '{"query":"{a{b{c{d{e{f{g{h{i{j}}}}}}}}}}"}'
{"errors":[{"message":"Cannot query field \"a\" on type \"Query\"."}]}
HTTP 400 / GraphQL validation error — the query never reaches resolution, so depth is never actually tested, on DVGA or on any other real schema.
Suggested fix
Introspect the schema first (or accept a small number of known-valid field names via config) and build the deep-nesting probe out of fields that actually exist on the target, so it reaches the resolver layer where depth limiting would apply. Alternatively, fall back to a generic recursive fragment technique that doesn't require guessing field names.
Impact
The depth/complexity-limit check will report "no issue found" on every real target regardless of whether depth limiting is actually configured — a systematic false negative.
Companion to #70 — found during a manual verification pass of ASTF v1.0.0 against VAmPI, crAPI, DVGA, and gRPC Goat.
Summary
GraphQLSecurityTestCase's query-depth/complexity check sends a hardcoded deeply-nested probe query using placeholder field names (a,b,c, ...j). Any real GraphQL schema rejects this at schema-validation time (HTTP 400, "Cannot query field ...") before the query is ever executed — so the depth-limit test can never observe whether depth limiting is actually enforced. As implemented, this check is dead code against real targets.Location
src/main/java/org/owasp/astf/testcases/GraphQLSecurityTestCase.java(deep-query constant /testQueryDepthAttack-style method)Reproduction
Scanned DVGA (
/graphql) with ASTF v1.0.0. Introspection and batch-query-abuse were correctly detected, but no depth-limit finding was ever produced. Replaying the exact probe payload by hand against DVGA:HTTP 400 / GraphQL validation error — the query never reaches resolution, so depth is never actually tested, on DVGA or on any other real schema.
Suggested fix
Introspect the schema first (or accept a small number of known-valid field names via config) and build the deep-nesting probe out of fields that actually exist on the target, so it reaches the resolver layer where depth limiting would apply. Alternatively, fall back to a generic recursive fragment technique that doesn't require guessing field names.
Impact
The depth/complexity-limit check will report "no issue found" on every real target regardless of whether depth limiting is actually configured — a systematic false negative.
Companion to #70 — found during a manual verification pass of ASTF v1.0.0 against VAmPI, crAPI, DVGA, and gRPC Goat.