API Penetration Testing for REST and GraphQL: What Most Tools Miss
Security scanners are good at finding what they already know. They match patterns, check headers, and flag known CVEs. What they cannot do is think through an authentication flow, notice that a GraphQL introspection query reveals an admin-only mutation, and then chain that discovery into a privilege escalation attempt.
That gap - between automated scanning and real penetration testing - is where API vulnerabilities live.
Why API Testing Is Harder Than It Looks
REST and GraphQL APIs are not just HTTP endpoints with JSON payloads. They carry session logic, authorization models, token lifecycles, and inter-service trust that a scanner sees as opaque. The OWASP API Security Top 10 exists specifically because API attack surface differs from web application attack surface. Broken Object Level Authorization (BOLA), broken function-level authorization, and excessive data exposure all require the tester to understand business logic, not just HTTP semantics.
GraphQL adds a layer on top of that. A single endpoint accepts arbitrary queries. Introspection can expose schema. Nested queries can trigger denial-of-service without a single CVE involved. Tools built for REST often bolt on GraphQL support as an afterthought and miss the depth the protocol requires.
What Real API Penetration Testing Covers
A credible API pentest goes through at least the following:
OWASP API Security Top 10 - Full coverage across all 10 risks, including BOLA, broken authentication, and unrestricted resource consumption. Not just checklist acknowledgment - actual exploitation attempts.
Authentication and OAuth 2.0 flows - Weak signing algorithms, token leakage, replay attacks, token scope creep, and API key management. OAuth 2.0 in particular has enough edge-case misconfigurations that it deserves its own testing pass.
API-specific discovery - Auto-ingesting API specs (OpenAPI, Swagger, GraphQL schema) to understand the attack surface before testing begins, rather than crawling blind.
Authorization logic - Whether a user at one privilege level can access, modify, or delete objects belonging to another user. BOLA is consistently the highest-impact API vulnerability, and it requires exercising the API as multiple identities, not just as an anonymous requester.
The Agentic Difference
RedPick approaches this as an AI-agentic platform - meaning the testing engine plans and chains exploit attempts the way a human pentester would, not the way a scanner would. It reads the API spec, forms hypotheses about what could go wrong, executes attempts, and adjusts based on responses.
That matters for APIs specifically because:
- GraphQL introspection is a starting point, not an end. An agentic tester uses schema discovery to plan mutation attacks, not just to report "introspection is enabled."
- Auth bypass is contextual. The same JWT misconfiguration might be exploitable in one flow and inert in another. A chained approach finds the exploitable path; a scanner finds the misconfiguration and stops.
- BOLA requires perspective-switching. Testing whether User A can read User B's records requires the test to operate as User A with User B's resource identifiers in scope. Agentic planning handles this; pattern matching does not.
RedPick operates black-box by default - no source code or credentials required to start a test. It can run on-demand or integrate into a CI/CD pipeline for continuous testing as your API evolves.
REST vs. GraphQL: Same Depth, Different Shape
REST API testing and GraphQL testing share the same underlying risk categories - authentication, authorization, input validation, rate limiting - but the attack surface looks different.
For REST, the surface is a collection of discrete endpoints with defined HTTP methods. Testing covers each endpoint, each parameter, and how they interact across authenticated and unauthenticated sessions.
For GraphQL, the surface collapses to one endpoint but expands into an arbitrarily complex query space. Testing has to account for:
- Schema exposure via introspection
- Query complexity and depth limit enforcement (or lack of it)
- Field-level authorization - a type may be accessible, but specific fields may not be
- Batching attacks that bypass rate limiting by bundling requests
RedPick tests REST, GraphQL, and SOAP APIs with the same depth - meaning the same agentic planning and exploitation logic, shaped to the protocol.
How This Differs From a Scanner or a Manual-Only Engagement
Traditional DAST tools find surface-level issues: exposed headers, known CVE patterns, basic injection points. They do not chain findings or reason about authorization context. They are useful and they are not sufficient for APIs.
Traditional manual pentests find deep issues but are time-bounded and expensive to repeat. A two-week engagement against an API that ships weekly is a snapshot, not coverage.
RedPick is priced per-test rather than by subscription, which means you pay for the test you need when you need it - not a recurring seat license for a tool your team may use intermittently. It also means you can run a test after a significant API change without justifying a retainer.
The AI-augmented approach means human pentesters can still be in the loop - the platform correlates AI findings in real time for human review rather than replacing the practitioner entirely.
Getting Started
If your API ships customer data, processes payments, or serves any authenticated business logic, a scan is not a substitute for a pentest.
RedPick is available through Apona. Tests cover REST, GraphQL, and SOAP APIs out of the box, with OWASP API Top 10 as a baseline and full auth and authorization testing beyond it.
Details at redpick.ai or reach out through apona.ai to talk through scope.
This post is about RedPick.