GraphQL security testing: why a single endpoint needs its own test
GraphQL security testing examines one HTTP endpoint that can expose many resources, checking the schema, field-level authorization, resolver behavior and query handling for the threats the OWASP GraphQL Cheat Sheet names: injection, denial of service, broken authorization including IDOR, batching attacks and insecure defaults. If your launch, customer security review, insurer or compliance assessment asks for GraphQL coverage, this is the test that answers it. A single /graphql path can serve customer records, payment data and administrative mutations, so the risk sits in how each field and resolver checks who is asking, not in whether the URL responds. Authorization is usually the decisive question, because a query can reach data through a relationship that the REST route it replaced would never have allowed.
Generic scanners struggle here for specific reasons. They rarely understand the schema well enough to build meaningful queries, they treat the endpoint as one URL rather than a graph of types, and they cannot judge whether a nested object should be visible to a given role. ASVS 5.0.0 states that automated DAST and SAST tools cannot fully verify many requirements, especially those on business logic and access control. A GraphQL test therefore needs the schema, the roles in use and test accounts at each privilege level, so the tester can compare what each identity should see with what the resolvers actually return.
Before commissioning the test, confirm four things with your engineering team: whether introspection and GraphiQL are enabled in production, which roles and tenants the schema serves, whether query depth, amount or cost limits and rate limits exist, and whether any persisted query or allow-list controls are in place. Each answer changes what the tester will probe and what evidence you should expect back. Ask the provider to show how they will map findings to the OWASP GraphQL Cheat Sheet controls and to the relevant OWASP API Security Top 10 2023 entries, since those mappings are what most reviewers will ask about. For regulated buyers, the report also matters. An ASVS-aligned verification report should list the requirements checked, the exceptions and the requirements that do not apply, rather than only a list of defects. Confirm that the provider can produce that structure, and that they run a hybrid test using the schema and documentation rather than blind probing. Testing that has no schema or role context will likely miss the authorization gaps that matter most.
What can be in scope for a GraphQL test
A GraphQL test is shaped less by the number of URLs than by how the schema is exposed, who can authenticate, and what sits between clients and resolvers. The decisions below determine which checks apply, how much authenticated coverage is needed, and how long the work takes.
Endpoints and schema versions
Confirm every GraphQL endpoint, including versioned paths, mobile-facing and partner-facing deployments, and staging or preview environments that share data. Each endpoint may expose a different schema, so each needs its own authorization review. Ask whether deprecated fields remain resolvable, since older fields often skip newer checks.
Introspection and GraphiQL access
Establish whether introspection is enabled and whether an interactive IDE such as GraphiQL is reachable from outside the network. A full schema map lowers the effort for every later test, and the OWASP GraphQL Cheat Sheet lists disabling introspection and GraphiQL in production as a core control. Record the answer as a finding in its own right if either is open.
Roles and test accounts
Agree which roles the tester needs, such as anonymous, standard user, tenant admin and support staff, and provide one account per role. Authorization in GraphQL is checked per field and per resolver, so unauthenticated coverage alone misses most broken access control. Ask for accounts in two tenants to test object-level access between them.
Persisted queries and gateways
Identify whether persisted or allow-listed queries, an API gateway or a web application firewall sits in front of the service. These controls can block arbitrary queries, so the tester needs either the allow-list or an agreed route that reaches the raw endpoint. Confirm which layer enforces depth, cost and rate limits, because the answer changes where the test looks for gaps.
Depth, cost and batching limits
Ask which limits are configured for query depth, query cost, alias count, batched operations and rate limiting, and where they are documented. Testing these controls requires agreed thresholds and a window in which load-generating checks can run without affecting shared services. Without these rules of engagement, the test either stays shallow or risks an outage.
Test data and environment rules
Define the environment, the data it holds and what the tester may create, modify or delete. Mutations, bulk reads and object identifier enumeration can expose or alter real customer records, so production testing needs written limits and synthetic data. Agree how findings involving personal data are handled and reported.
How a GraphQL engagement runs, phase by phase
The sequence moves from agreed scope and schema access to authorization testing, argument and abuse testing, a written report mapped to the controls, and a retest of the fixes.
Agree scope, schema access and test accounts
The client and DeployOpen agree in writing which GraphQL endpoints, environments and operations are in scope, and which roles the tester needs. The client supplies the schema if it is available (SDL or introspection output from a staging environment), any API documentation, a list of the user roles and tenants, and test accounts for each role plus an unauthenticated baseline. Scope also records whether introspection and GraphiQL-style explorers are enabled in the target, since the answer changes how the schema is obtained. The step is complete when the scope document names each endpoint, role and account, and the client has confirmed the test environment mirrors production controls closely enough to be meaningful.
Review the schema and exposed surface
The tester reads the schema before sending any test traffic beyond discovery. The review covers the types, queries, mutations and subscriptions, which fields are exposed, which types look sensitive (credentials, personal data, internal identifiers, administrative operations), and whether deprecated or undocumented fields remain reachable. The tester also checks what an unauthenticated caller can learn, including whether introspection, field suggestions in error messages and debug output reveal more than the public documentation does. The step closes with a schema map that the rest of the test uses as its checklist, and with a list of findings on information exposure, mapped to the GraphQL Cheat Sheet controls on introspection and GraphiQL.
Test authentication and unauthenticated access
The tester confirms which operations accept unauthenticated requests and whether each one should. This includes login, registration and password flows, as well as any query or mutation that returns data without a valid session or token. Token handling is checked at the gateway and at the resolver level, including expired, malformed and tampered tokens, and whether the server accepts tokens issued for another audience or service. The output is a table of every operation, its intended access level and the observed result for each role, which the tester uses to frame the authorization tests in the next step. Authentication weaknesses are reported against ASVS chapter V6 where they apply.
Check authorization on every field and resolver
This is the core of the engagement. The tester compares what each role can read and change, field by field, and object by object, using the account pairs agreed in scope. The checks look for broken object-level access (one user reaching another user's records through an identifier argument), missing checks on nested fields reached through a permitted parent object, mutations that skip the authorization applied to the matching query, and properties returned to lower roles that the schema should hide. Because GraphQL resolvers often enforce access differently from the gateway, the tester checks the resolver layer, not only the entry point. Findings are recorded against OWASP Top 10 2025 A01 and the relevant API Security Top 10 2023 items, and the step closes when every operation in the schema map has a recorded authorization result.
Test query cost, depth and batching behavior
The tester measures how the server handles expensive or repeated work. This covers nested queries that loop through related objects, aliases that repeat one expensive field many times in a single request, batched operations sent as arrays, and large list arguments. The aim is to confirm whether the server enforces the controls the GraphQL Cheat Sheet describes, including query depth limits, amount limits, query cost analysis and rate limiting, and whether those controls apply to batched requests as well as single ones. Tests run at volumes agreed with the client and inside the test environment, with the client's operations team informed. The output is a set of observed thresholds and a list of operations that can be driven into denial of service, each linked to API4 of the API Security Top 10 2023.
Test argument handling and insecure defaults
The tester sends crafted values through query and mutation arguments, input objects and variables to see how the server validates and passes them to back-end systems. The categories covered are injection into databases, search engines and downstream services, unsafe handling of file or URL inputs, and error handling that leaks stack traces, query text or internal names. The tester also reviews insecure defaults, such as verbose debugging enabled, GraphiQL reachable in production, permissive CORS, and GET requests accepted for mutations. Input validation findings map to ASVS V1 and V2, and injection findings to OWASP Top 10 2025 A05. The step closes with the list of arguments tested, the handling observed for each, and the configuration findings.
Report by requirement and retest the fixes
DeployOpen writes a report that lists each finding with its reproduction context, affected operations, risk rating, and the control it breaks, referenced to the WSTG API testing category and to ASVS V4 and V8 where the client needs assurance mapping. The report also records which operations were tested and found acceptable, and which requirements did not apply, so the client can show coverage to an auditor or customer. Remediation guidance is written for the development team in terms of schema design and resolver checks, not only the symptom. After the client applies fixes, DeployOpen retests the affected operations against the same test accounts and records whether each finding is closed, partially closed or still open. The engagement is complete when every finding has a retest result in the report.
How a GraphQL schema widens the attack surface
A GraphQL schema changes the attack surface because one request can reach many resolvers. A single query can traverse types, follow nested relationships and pull data from several backing services in one round trip. The schema is therefore a map of every path to data, not a list of endpoints. When a tester reviews a GraphQL service, the first decision is which types, fields and mutations are reachable by which roles, and whether the schema itself reveals more than those roles should see. Ask the development team for the authoritative schema, the role model behind it and a list of resolvers that call downstream services, because these define the paths the test must cover.
Authorization design gets harder in this model. Many teams place the access check on the top-level query or mutation, then let nested fields resolve freely. A user who is allowed to read their own order may be able to reach another customer's record through a relationship field, a list or a shared resolver that never re-checks ownership. The same gap appears when a field is reused across types or when a resolver fetches an object by identifier without confirming the caller's rights to that object. Testing has to walk each sensitive relationship from every role and compare what the resolver returns with what the business rules allow. Confirm whether authorization lives in a central policy layer or is repeated in each resolver, since the second pattern produces more gaps.
Batching and aliases create a rate limiting problem. GraphQL allows several operations in one HTTP request, and aliases let a single operation call the same field many times under different names. A limit that counts HTTP requests or top-level operations can therefore be far less protective than it appears, because one request may carry many executions of a sensitive action such as a login, a lookup or a payment step. Confirm with the team whether rate limits, query depth limits and cost analysis count resolver executions rather than requests, and whether they apply to batched operations. The OWASP GraphQL Cheat Sheet lists these controls as the main defenses against batching and denial of service, and the test plan should check each one against the actual configuration.
Which GraphQL weaknesses we test for and why they matter
This table maps each GraphQL weakness category in the OWASP GraphQL Cheat Sheet to how it typically appears in a schema-driven API, what we check for, and the business risk it carries. Read each row as a question to ask of your own GraphQL endpoint, then use the scope conversation to confirm which categories apply to your target. The main takeaway is that most GraphQL risk sits in authorization and resource limits, not in the query language itself.
| Weakness category | What it looks like in this target | Business risk |
|---|---|---|
| Introspection and debug exposure | The schema, types and field descriptions are readable by unauthenticated callers, and development tools such as GraphiQL or Playground respond on production hostnames. | Attackers get a complete map of data and operations, which speeds up every later test and exposes internal or deprecated fields. |
| Field and resolver authorization (IDOR) | Resolvers return objects by identifier without checking that the caller owns or may view them, or nested fields reveal data that the parent query would have blocked. | Cross-customer data exposure, which is the GraphQL form of broken object level authorization (API1:2023) and a leading A01 concern. |
| Nested query depth and cost | Recursive or deeply nested selections are accepted without a depth limit or query cost analysis, so one request fans out across many resolvers and database calls. | Denial of service against shared services and unpredictable infrastructure cost, which maps to API4:2023 unrestricted resource consumption. |
| Batching and alias abuse | Many operations or repeated aliases run in one HTTP request, which can bypass per-request rate limits and login throttling. | Credential guessing, one-time code brute force and scraping that look like normal traffic to rate limiters. |
| Injection through arguments | Arguments flow into database queries, search filters, file paths or downstream calls without parameterization or validation. | Data disclosure or modification through the backend, mapped to A05 Injection and the input validation chapter of ASVS. |
| Insecure defaults such as GraphiQL in production | Interactive consoles, verbose debugging flags, permissive CORS or unrestricted methods remain enabled after a deployment from a template or framework default. | Lowered barrier for every other weakness, and a configuration finding under A02 Security Misconfiguration. |
| Error detail leakage | Stack traces, resolver names, SQL fragments or internal hostnames appear in the errors array of responses. | Internal design details reach attackers, and the leakage often proves a second weakness exists, relevant to A10 Mishandling of Exceptional Conditions. |
How GraphQL testing differs by architecture
In a federated or gateway-based graph, a router or gateway composes several subgraphs, each owned by a different team and often deployed separately. The schema a client sees is assembled at the edge, so a test that only exercises the gateway can miss authorization rules that live inside individual subgraphs. Scope therefore has to name every subgraph that resolves data reachable through the supergraph, plus the gateway's own configuration. Authorization is usually split: the gateway may enforce coarse rules, while each subgraph's resolvers decide object-level access. Evidence should show which layer enforced each finding.
- Subgraph-level coverage: Each subgraph needs its own test pass, including direct access where the network allows it, since a subgraph reachable without the gateway bypasses gateway rules.
- Entity resolution: Testing should cover how references between subgraphs resolve, because a resolver that trusts a reference from another service can expose data the caller should not see.
- Introspection and schema composition: Confirm whether the composed schema exposes fields from internal subgraphs that the public schema should hide.
- Ownership mapping: Ask the client which team owns each subgraph so findings reach the right remediation owner.
- Configuration review: Include the gateway's query limits, cost settings and error handling, which can differ from subgraph settings.
Before testing, ask the client for the composed schema, the list of subgraphs and the gateway configuration, and confirm which subgraphs are reachable from outside the network.
A single GraphQL server runs one schema, usually behind one endpoint and one set of middleware. This makes scope simpler to draw and authorization easier to trace, because the resolvers, data access layer and limits sit in one codebase. The risk concentrates in consistency: a field added late in development may skip the authorization helper that other resolvers use. Testing a monolith therefore focuses on whether every type and field follows the same access pattern, and on whether controls like depth limits and rate limits apply to the single endpoint as intended.
- Whole-schema walk: Map every type and field so authorization coverage can be checked against the full schema, not a sample.
- Single control point: Verify that query depth, amount and cost limits are enforced in the server, not only in a client library.
- Batching behavior: Confirm how the server handles multiple operations in one request and whether rate limits count them correctly.
- Consistent resolver patterns: Look for fields that bypass the shared authorization helper.
- Debug and development features: Check whether the GraphiQL interface or verbose error output remains enabled in the deployed environment.
When the client provides the schema file and source access, a documentation-led test can cover the full schema, which is what the OWASP GraphQL Cheat Sheet controls are designed to check.
Exposure changes the threat model more than the code does. A public GraphQL endpoint accepts requests from anyone who can reach it, so unauthenticated behavior, introspection, error messages and denial-of-service controls are central. An internal endpoint, such as one used only by a back-office application or a partner network, may assume trusted callers, and that assumption is often where authorization gaps hide. Scope for each should state the network position, the identities that can call the endpoint and the data each identity should reach.
- Unauthenticated surface: For public endpoints, test which operations and fields answer without a valid session.
- Trust assumptions: For internal endpoints, test what happens when a caller inside the network holds a low-privilege account or a stolen token.
- Schema disclosure: Check whether internal schema details are visible through a public path, including introspection and error text.
- Rate and cost controls: Public endpoints usually need stricter limits per client and per operation.
- Test accounts: Ask for accounts at each privilege level, plus one account per tenant where the platform is multi-tenant.
Confirm with the client which endpoints are internet-facing and which are reachable only through VPN, private links or service meshes, because that position determines which tests are in scope.
Many organizations run GraphQL next to REST endpoints that serve the same data, sometimes through a shared backend and sometimes through separate services. The two interfaces often apply authorization differently: a REST route may check ownership on every request while the GraphQL resolver for the same object checks only the session. Scope should therefore pair equivalent operations across both interfaces and compare the results. Evidence should show whether the same user receives the same data, and where the mismatch sits, since that comparison is hard to make from either interface alone.
- Paired operation mapping: List REST routes and GraphQL operations that expose the same objects, and test them together.
- Authorization parity: Confirm that each object-level and function-level rule holds in both interfaces. The OWASP API Security Top 10 2023 is a useful reference for these checks.
- Shared credentials: Check whether tokens issued for one interface are accepted by the other with different scopes.
- Inventory completeness: Ask whether any GraphQL endpoints or REST routes are undocumented, since shadow interfaces often appear during migration.
- Evidence format: Record paired requests and responses so the client can see the comparison, not only the individual findings.
Before testing, ask for the REST specification, the GraphQL schema and a list of test accounts that work across both interfaces.
What drives the cost and duration of a GraphQL test
This table compares the components that move the price and length of a GraphQL security test, who is paid for each, and whether the cost is one-time or recurring. Use it to check that a written quote states the schema size, role count, test depth and retest terms it depends on. No price or duration is implied, since DeployOpen quotes follow from the agreed written scope.
| Cost component | Who is paid for what | One-time or recurring | What to request in a written quote |
|---|---|---|---|
| Number of types, queries, mutations and subscriptions | Tester time to enumerate, map and exercise each operation and its arguments | One-time per test cycle | Schema operation count, or the introspection output and the operations in scope |
| Roles, tenants and privilege levels | Tester time to build and compare access matrices for field and resolver authorization, including cross-tenant object references | One-time per test cycle, grows with each role added | List of roles, tenant boundaries and which operations each role may call |
| Schema and documentation provided | Tester time to reconstruct the schema if introspection is disabled, or to validate documented behavior if it is provided | One-time, usually lower when a current schema is supplied | Whether a current schema, SDL file or gateway configuration will be shared before testing starts |
| Authenticated versus unauthenticated coverage | Tester time for test accounts, session handling and testing as each authenticated role | One-time setup, plus repeat effort for each additional identity provider or login path | Which tests run unauthenticated, which run per role, and who provisions test accounts |
| Depth of query cost, depth and batching testing | Tester time to check depth limits, cost analysis, alias and batching behavior and rate limiting under controlled load | One-time per test cycle, with more effort where limits are configured per operation | Whether limit testing is included, the load boundaries agreed in writing and the target environment |
| Number of environments | Tester time to confirm configuration and defaults such as introspection and GraphiQL exposure in each environment | One-time per environment tested | Named environments, whether production is in scope and the testing window for each |
| Retest after remediation | Tester time to confirm fixes for each finding and record the outcome | Recurring per retest round, usually a separate line item | Number of retest rounds included, the time window for retest and the evidence format delivered |
| Reporting and evidence format | Tester time to write findings and map them to OWASP GraphQL Cheat Sheet controls and any framework the client needs | One-time per test cycle, larger when an assessor expects a detailed control mapping | Report format, control mapping requirements and whether an auditor or customer template must be followed |
What the report must show to satisfy an auditor or customer
A GraphQL test report must show what was checked, not only what failed. A conventional penetration test report lists issues by exception: the findings are present and everything else is implied to be fine. ASVS 5.0.0 describes a different artifact for verification work. An ASVS-style verification report states the scope, summarizes every requirement checked, identifies the requirements with exceptions and the guidance for resolving them, and notes the requirements that do not apply. For a GraphQL endpoint, that means the report should list each schema-level and resolver-level control that was verified, including the ones that passed, such as whether introspection is disabled in the production environment, whether depth and amount limits are enforced, and whether each sensitive field and mutation enforces authorization. An auditor or customer can only judge coverage from that full list. Agree on the report type before testing starts, because retrofitting a list of passed checks after the fact is slow and often incomplete.
Map every GraphQL finding to two references: the relevant control in the OWASP GraphQL Cheat Sheet and the ASVS requirement it affects, typically in V4 API and Web Service, V8 Authorization or V2 Validation and Business Logic. The Cheat Sheet's controls, such as query depth and amount limits, query cost analysis, rate limiting, disabling introspection and GraphiQL in production, and protection against batching abuse, give the remediation owner a concrete target. The ASVS mapping tells the auditor which requirement the evidence supports. Ask the provider to show, for each finding, the affected query or resolver, the role used for testing, the expected and observed behavior, and the retest outcome. Note that DeployOpen prepares this evidence, including test records, control mappings and remediation tracking, for the client's assessor. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, and the client should confirm early which body will accept the evidence.
What you receive at the end of a GraphQL test
A GraphQL test ends with a set of documents that serve different readers: executives, developers, the team that owns the schema, and the auditors or customers who ask what was covered. Each deliverable below is something the client holds, and together they show what was tested, what was found, and what has been fixed since.
Executive summary
A short document for leadership that states the scope, the overall posture of the GraphQL endpoints tested, and the findings that carry the most business risk, such as object-level authorization gaps that expose customer records. It avoids query syntax and explains each risk in terms of the data or function it affects, so decision makers can prioritize remediation without reading the full report.
Scope and method record
A written record of the endpoints, schema version, environments, roles and test accounts used, plus the tools and manual techniques applied. It lists what was excluded and why, including any introspection or GraphiQL behavior observed in each environment. Ask for this record early, because it is what an auditor or customer reviews first to judge how much the test covered.
Schema-level findings
Each finding names the affected types, fields, arguments and resolvers, so the engineering team can locate the code without guessing. Typical items include introspection exposed in production, field suggestions that reveal hidden types, and arguments accepted without validation. Each entry records the GraphQL mapping to the OWASP GraphQL Cheat Sheet control it relates to.
Authorization test matrix by role
A grid that shows, for each role and test account, which queries, mutations and fields were permitted, denied or unexpectedly returned data. Because GraphQL exposes many paths to the same object, the matrix is the clearest evidence of field and resolver authorization. Use it to confirm that a restriction on one query is enforced on every alternative route to the same data.
Severity and developer reproduction notes
Each finding carries a severity rating, the conditions needed to trigger it, and reproduction notes written for developers, without operational exploit code. The notes describe the request shape in general terms, the expected and observed responses, and the logging evidence. Ask the tester to state how severity was assigned, since GraphQL denial of service findings depend heavily on the depth, cost and rate limits actually configured.
Remediation guidance and retest results
Remediation guidance explains the control to apply for each finding, such as query depth and amount limits, query cost analysis, or disabling introspection and GraphiQL in production. After fixes are deployed, a retest records which findings are closed, which remain open and why, and what changed. The retest report is the document that shows the fixes were verified rather than assumed.
Scope letter for customers or auditors
A letter that describes the GraphQL testing performed, its dates, its scope and its methodology, written so a customer's security review or an auditor can cite it. DeployOpen does not issue audit reports or certifications, so this letter is evidence of testing only. Confirm with your auditor or customer which wording and attestations they accept before the test begins.
What your team prepares before testing starts
The fastest way to lower the effort of a GraphQL test is to hand the tester the schema before the work starts. Ask your platform or API team for a full schema export from the test environment, or confirm that introspection is enabled there for the tester's accounts. Without it, the tester has to reconstruct types, mutations, subscriptions and hidden fields by probing, which adds hours that produce no new findings. Ask for the schema in its current form, with any deprecated fields included, because deprecated fields are a common place for authorization checks to be missed. Also confirm whether introspection is disabled in production. If it is, say so in writing, since the test will then check that the production setting is enforced rather than relying on the schema export. Next, provide documented roles and permissions and at least one test account per role and per tenant. GraphQL authorization is often enforced at the resolver level, so the tester needs to compare what each role can query, mutate and read through each field, including nested objects reached through relationships. Two accounts in the same role but different tenants are what let the tester check object-level isolation, which is where insecure direct object references usually appear. Seeded test data matters here too: each account should own records the other accounts can be checked against, otherwise cross-user reads cannot be confirmed. Confirm with your team which fields are sensitive, because the tester will focus there first. Finally, agree the operational items that prevent disruption. Confirm the rate-limit, query depth and query cost settings that the test environment should match, and agree in writing whether the tester may exceed them for a bounded period. Name a technical contact who can answer schema questions and who can stop the test. Ask your monitoring team whether alerts from the tester's source addresses should be suppressed, logged, or allowed to fire, and record a change freeze window so that a deployment does not change the schema or resolvers mid-test. A test environment that differs from production in these controls will produce findings that do not apply, or miss ones that do, so confirm the match before testing begins.
GraphQL security testing questions buyers ask
Does introspection have to be enabled for a GraphQL security test?
No. Introspection is not required, but enabling it for the test window makes the review faster and more complete, because the tester can map types, queries, mutations and arguments directly from the schema. If introspection is disabled in production, the usual approach is to test against a staging or pre-production instance that mirrors production configuration, or to supply the schema file so the tester can work from it. Whichever route is chosen, record the decision in the scope. Disabling introspection is a control to verify, not a substitute for authorization checks, since the OWASP GraphQL Cheat Sheet treats it as one of several defaults to harden alongside depth limits and cost controls. Confirm with the client whether GraphiQL or similar explorers are exposed in the environment under test.
Can a GraphQL API be tested without its schema?
Yes, but coverage is usually lower and the work takes longer. Without a schema, the tester must discover operations from the client application, captured traffic and error messages, and some field-level authorization paths may stay unseen. Error messages sometimes reveal type or field names even when introspection is off, and the test can still check whether those messages leak internal detail. The stronger approach is documentation-led testing: the client supplies the schema, the resolver map where it exists, the list of roles and a set of test accounts. ASVS 5.0.0 encourages this hybrid style over testing without documentation or source, and that principle applies directly to GraphQL. Ask the provider how they will enumerate operations when no schema is available and what they will record as untested.
What drives the cost of a GraphQL security test?
The main drivers are the number of distinct operations, the number of roles and tenancy boundaries to test, the depth of the resolver logic that enforces access, and whether the tester has the schema, test accounts and a non-production environment. Each of these changes how many authorization comparisons and abuse scenarios the tester must run. Cost is one-time for the assessment, while retesting and any continuous testing are recurring. A quote should state the in-scope endpoints and operations, the roles and accounts used, the environment, the methodology (for example, WSTG categories and ASVS chapters), whether testing is authenticated, the deliverables, the retest terms and the reporting format. Ask the provider to list exclusions in writing. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does a GraphQL security test take?
Duration depends mainly on the size of the schema, the number of roles, how many resolvers enforce access in non-obvious ways, and how quickly the client provides accounts, schema access and clarifications. Teams often lose time waiting for test accounts or a stable staging build, so those dependencies should be confirmed before the test window is set. The testing itself is a mix of automated discovery and manual analysis, and manual analysis of authorization and business rules takes the most time. No duration is set here because it must follow from a written scope for a specific API. Ask the provider for a schedule that separates preparation, testing, reporting and any retest, and for the dependencies on the client side.
Is authenticated testing required for GraphQL?
For most production GraphQL APIs, yes. Many of the risks that matter most, including broken object level authorization and field-level access, only appear when the tester holds valid sessions for different roles and compares what each can read or change. CIS Controls v8.1 Safeguard 16.13 notes that for critical applications, authenticated testing is better suited than automated scanning to finding business logic flaws, with testers acting as both authenticated and unauthenticated users. Unauthenticated checks still matter for exposed endpoints, error handling and rate limits. Ask the provider to test with at least two accounts per relevant role, plus an unauthenticated baseline, and to document which operations were reached under each identity.
Does a GraphQL security test include a retest?
Whether a retest is included depends on the written scope and the commercial terms, so it should be confirmed in the quote rather than assumed. A typical retest checks that each finding has been fixed, confirms that fixes did not break legitimate access, and updates the report status. Most engagements are fixed-scope, so the retest window, the number of retest rounds and the deadline for requesting it should be stated in writing. Ongoing testing as work continues on the API is available as a retainer. Ask whether retest effort is priced separately and how long after the report it remains available.
Will a GraphQL test report satisfy PCI DSS or ASVS assessors?
It can support an assessment, but it does not replace one. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. For PCI DSS, requirement 11.4.1 calls for application-layer penetration testing that covers the vulnerabilities in requirement 6.2.4, including business logic abuse through API manipulation, so the test scope must be set to meet that requirement and the assessor must accept the tester's qualifications. ASVS 5.0.0 expects a verification report to list the scope, a summary of every requirement checked, the requirements with exceptions and guidance, and any requirements that do not apply, which differs from a traditional list of findings. Ask the assessor which format they accept before the test starts, and ask the provider whether they hold OVS accreditation for ASVS assessments, which CREST announced in October 2022.
What to check when choosing a GraphQL testing provider
GraphQL changes what a tester must read, query and authorize against, so a generic API scan rarely answers the questions that matter. The cards below cover the checks that connect method, access, scope, deliverables and retest terms, and that you can put to a provider before you sign.
Demonstrated GraphQL method
Ask for a written method that starts from the published schema and works through introspection status, field-level authorization, depth and cost limits, batching and argument handling. A provider who only runs a generic API scanner against the endpoint will miss resolver-level access checks. Ask how they handle schemas that have introspection disabled, and what they record when they cannot map the full graph.
Mapping to the GraphQL Cheat Sheet
The OWASP GraphQL Cheat Sheet names injection, denial of service, broken authorization including IDOR, batching attacks and insecure defaults as the main threats. A credible provider organizes its test plan around those categories and ties each finding to a control, such as query depth limits, cost analysis, rate limiting or disabled GraphiQL in production. Ask for that mapping in the sample report.
Authenticated testing with multiple roles
Most GraphQL authorization flaws only show up when the tester holds several accounts, such as a standard user, an administrator and a customer from another tenant, and compares what each can read or mutate through the same schema. Confirm the provider will test as authenticated users with distinct roles, as CIS Control 16.13 describes for critical applications, and that they need those accounts and the schema supplied before the work starts.
ASVS method and CREST OVS status
If the test feeds an ASVS verification, ask whether the provider has CREST accreditation under the OWASP Verification Standard for ASVS web assessments, and ask for the accreditation scope in writing. Accreditation is held by the testing organization, so it must be confirmed for the firm, not assumed from an individual's certificate. Also ask which ASVS level and chapters the test covers, such as V4 API and Web Service and V8 Authorization.
Written scope and fixed deliverables
Require a written scope that lists the GraphQL endpoints, schema versions, roles, environments and exclusions, along with the deliverables and the acceptance criteria for each. Most engagements at DeployOpen are fixed-scope, and any provider should be able to explain what changes the price if the schema grows or new roles are added. Ask what the report contains, how findings are rated and whether a reader can trace each one to a schema field or resolver.
Retest terms and their limits
Ask whether the quote includes a retest of fixed findings, how many retest rounds are covered, how long after the report the retest window runs and whether the retest uses the same roles and schema. Clarify whether a retest confirms the fix or only checks the original payload path, because a GraphQL fix can close one resolver while leaving a sibling field open. Get these terms in writing before signing.
How DeployOpen scopes, tests, reports and retests GraphQL
DeployOpen is a Chainscore Labs company that runs application and API security testing inside the client's own environment, and a GraphQL engagement starts with a written, fixed scope. Before any testing begins, the scope should name the endpoints, the environments (production, staging or a copy of production), the roles and test accounts to be used, the schema version under review and the GraphQL-specific areas to cover, such as introspection, field-level authorization, depth and cost limits, batching and argument handling. The deliverables, the timeline and the retest terms are agreed in the same document. Ask for the scope in writing before signing, and confirm whether the client will supply the schema, the resolver authorization rules and at least two test accounts per role, since those inputs decide how much of the work can be done against documentation rather than by guesswork.
Testing is documentation-led. The tester works from the schema, the role matrix and the authorization design, then checks each field and mutation against the roles that should and should not reach it, including object-level checks on identifier arguments and property-level checks on returned fields. Automated scanners and introspection tools help map the surface, but ASVS 5.0.0 notes that automated tools cannot fully verify access control or business logic, so the manual portion carries most of the weight. The report should follow the structure that ASVS 5.0.0 describes for verification reports: scope, a summary of the requirements checked, the findings with exceptions and remediation guidance, and the requirements that do not apply. Where the client needs a pure penetration test report, DeployOpen can structure findings so they map to the GraphQL Cheat Sheet controls and the relevant OWASP Top 10 and API Security Top 10 entries. Confirm with your auditor which format they will accept.
Retesting is part of the scope, not an extra. Ask for the number of retest rounds, the window in which fixes are verified and whether retests are included in the fixed fee. For teams that change the schema often, an optional retainer can cover recurring testing of new mutations and changed authorization rules, with the same written scope terms applied to each cycle. DeployOpen does not issue audit reports, attestations or certifications, so any compliance evidence it produces should be submitted to the independent assessor the client's framework requires. Confirm with that assessor what evidence format they need before testing starts.
