Teams should treat API security as part of the delivery workflow, not a separate cleanup phase. A practical approach is to combine runtime scanning with architecture review, then feed the findings into CI/CD so issues are identified before production. That lets engineering teams remediate faster, reduce rework, and keep security checks aligned with release cadence.
Where GraphQL security reviews belong in the delivery workflow
GraphQL reviews work best when they are attached to the same delivery checkpoints that shape schema changes, resolver logic, and client access patterns. The practical question is not whether security can be done later, but which pipeline stage can catch authorization drift, overexposed fields, and unsafe query patterns before they become production defaults.
For teams that want a repeatable model, the review should sit beside schema design, code review, test execution, and release gating. That is where security findings can be tied back to the exact operation, resolver, or field change, rather than being treated as a generic post-release hardening task. A delivery-first approach also makes it easier to keep the review aligned with how GraphQL actually evolves, which is often faster than traditional API change cycles.
At the control level, this means combining static checks on schema and query handling with runtime testing of exposed endpoints. The most useful checks are the ones that can answer whether the change introduces new data exposure, weakens authorization boundaries, or increases the chance of abusive query execution. A good review process therefore focuses on the concrete behavior of the API, not just whether a spec exists.
- Validate schema changes before merge, especially new fields, mutations, and deprecated paths that can widen access.
- Run security tests against real query shapes, including introspection, depth, batching, and abuse of expensive operations.
- Block release when a change alters access rules, data scope, or rate-limiting behavior without explicit sign-off.
What to check in CI/CD for GraphQL-specific failure modes
GraphQL creates a few failure modes that are easy to miss if a pipeline only checks for generic API defects. Overly broad schemas can expose data that should stay hidden, while resolver logic can bypass the intended access model even when the schema looks correct. Query flexibility also means a valid request can still be operationally dangerous if it drives excessive backend work or pulls too much data.
That is why the strongest reviews test both the contract and the execution path. Contract checks should confirm that the schema does not reveal unnecessary fields or privileged operations, and execution checks should confirm that resolvers enforce the same authorization assumptions at runtime. Teams should also verify that the pipeline can distinguish safe functional changes from changes that expand the blast radius of a compromised client or token.
Security reviews are strongest when they are tied to known API failure classes. The OWASP API Security Top 10 remains a useful way to frame GraphQL review criteria, and the OWASP Web Security Testing Guide is helpful when teams need a repeatable test method for query handling and access control validation.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | GraphQL and API Security in Delivery Pipelines | GraphQL delivery pipelines need API security review and abuse testing |
| Recommendation — Embed schema, resolver, and query abuse checks into each release gate. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | GraphQL pipelines need secure build, test, and release controls for application logic |
| Recommendation — Integrate security testing into the software delivery pipeline before production release. | ||
| NIST CSF 2.0 | PR.DS — Data Security | GraphQL reviews must prevent unintended data exposure through schemas and resolvers |
| PR.AC — Identity Management, Authentication and Access Control | GraphQL review must confirm field and resolver authorization stays intact | |
| DE.CM — Continuous Monitoring | Runtime scanning and pipeline telemetry are needed to catch GraphQL abuse patterns | |
| Recommendation — Verify that GraphQL controls limit data exposure across schema and runtime paths. Enforce access control checks at schema and resolver enforcement points. Monitor GraphQL traffic and query behavior for misuse and policy drift. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | GraphQL delivery pipelines often rely on tokens and secrets that must not leak |
| NHI-05 — Overprivileged Non-Human Identities | CI/CD and service credentials used for GraphQL delivery can hold excessive access | |
| NHI-08 — Third-Party and Supply Chain Risk | GraphQL delivery pipelines depend on actions, libraries, and tooling that can be abused | |
| Recommendation — Protect API secrets used in GraphQL CI/CD and rotate them on exposure. Reduce GraphQL pipeline credentials to the minimum permissions needed. Review third-party pipeline dependencies that can alter GraphQL build or release integrity. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | GraphQL endpoints are public-facing apps that can be exploited through API weaknesses |
| T1056 — Input Capture | GraphQL abuse often starts with crafted queries and payloads that manipulate execution | |
| Recommendation — Hunt for exploit patterns in exposed GraphQL endpoints and route them into detection. Test and detect malicious query input patterns before they reach production services. | ||
Practitioner Guidance
What to prioritise: Put authorization and data exposure checks ahead of cosmetic schema validation. In GraphQL, the biggest mistakes are usually not syntax failures, they are field-level access drift, resolver gaps, and queries that are valid but operationally unsafe.
What to verify: Confirm that the pipeline tests the exact path from schema to resolver to backing service. If security only checks the schema document, it will miss the point where access control is actually enforced or bypassed.
Common mistake: Treating GraphQL security as a one-time hardening step after implementation. Teams get better outcomes when the pipeline makes security review a merge-time and release-time gate, because the risk changes with every schema and resolver change.
Practitioner takeaway: The most effective GraphQL security program is one that proves each release preserves access boundaries, not one that merely documents them.
Related resources from NHI Mgmt Group
- How should security teams integrate code scanning into Bitbucket Cloud pipelines without slowing delivery?
- How should security teams integrate PAM into DevSecOps pipelines to reduce privileged access risk without slowing delivery?
- How should security teams integrate source code protection into DevSecOps pipelines without slowing delivery?
- How should security teams reduce risk in software delivery pipelines with NHI controls?
