API Security Testing Checklist: Shadow APIs, Verb Gaps, GraphQL and gRPC
APIs now carry more sensitive traffic than the websites in front of them. This testing checklist covers shadow APIs, verb gaps, GraphQL and gRPC exposure, and broken authorization.
Modern websites are thin skins over API backends. The login form, the dashboard, the mobile app — they all talk to the same API surface, and that surface usually exposes far more than the UI uses. API security testing is therefore not a niche discipline; it is where most of the real attack surface lives. This checklist walks through the vulnerability classes that matter in 2026, how a scanner tests each one, and what a fix looks like.
1. Shadow APIs: The Endpoints Nobody Admitted To
The problem. Shadow APIs are endpoints that exist in production but are absent from documentation, the gateway inventory, and (often) the security team's awareness. They come from old feature branches never cleaned up, debug routes, internal tools exposed by accident, and deprecated versions kept "temporarily" in 2022.
How to find them. Discovery has to work from the outside in, combining:
- OpenAPI/Swagger documents — the OpenAPI-driven API Security Testing check parses any reachable spec and tests every declared operation, but a spec only covers what it declares
- Historical URL mining — archives, crawlers, and JS bundle analysis reveal endpoints that no spec mentions (the Shadow API Discovery scanner combines wayback-style historical data with JavaScript analysis)
- JavaScript bundle analysis — modern SPAs hard-code their API routes into shipped bundles; extracting them yields the true endpoint inventory
The fix. Inventory your routes at the gateway, kill what you do not serve, and require new endpoints to be declared before deployment.
2. Verb Gaps and Method Confusion
The problem. Access controls are frequently implemented per HTTP method — GET /api/users demands a session, while HEAD, OPTIONS, or even PUT on the same path slip past. A scanner comparing GET /api/admin (401) with HEAD /api/admin (200, full headers) has found an access-control bypass that a browser-based test would never notice.
How to find them. The API Verb Gap check probes each discovered endpoint across methods and compares authentication verdicts — a differential test with a clear baseline, so method-level inconsistencies surface reliably.
The fix. Enforce authentication and authorization in middleware that runs before routing, not per-handler.
3. GraphQL: Introspection, Depth and Authorization
GraphQL brings its own failure modes:
- Open introspection discloses your entire schema — every type, every field, every mutation — handing attackers a complete map
- Deep queries (
user { posts { author { posts { author { … } } } } }) enable denial-of-service at the resolver layer - Field-level authorization gaps appear because GraphQL blurs endpoint boundaries: the
emailfield may be protected on one query but not another
A dedicated GraphQL scanner tests introspection availability, probes for authorization differences between similar queries, and attempts safe depth-abuse patterns to see whether limits exist.
4. gRPC and Reflection
gRPC services increasingly expose public endpoints, and server reflection is the protocol's gift to attackers: a reflection-enabled service happily enumerates every available method and its message schema. From there, unauthorized method invocation becomes a matter of patience. The gRPC Reflection Scanner checks whether reflection is enabled and whether methods are callable without credentials.
5. IDOR / BOLA: The Owasp API #1
Insecure Direct Object References (called BOLA in the OWASP API Top 10) remain the most common serious API flaw: endpoint returns object by ID, ID belongs to another user, authorization never checked. It is why GET /api/invoices/1043 should terrify any team that has not tested it.
Scanners approach IDOR in two layers: a pattern layer that identifies ID-shaped parameters and endpoints returning different objects by ID (flagging them for review with concrete test cases), and — on authenticated scans — an opt-in isolation proof using two test sessions to demonstrate whether one account can actually read another's data. The second layer is the only honest way to prove BOLA; the first is how you find where to look.
6. Hidden Parameters: The Attack Surface You Can't See
Applications accept parameters the UI never sends: debug, admin, internal, test, feature flags, legacy fields. Attackers find them by fuzzing; so should your scanner. Hidden parameter discovery (the Arjun-based check) probes each endpoint with thousands of candidate parameter names and detects which ones change the response — every accepted parameter is new attack surface, and debug parameters in particular have a long history of enabling authentication bypasses and information disclosure.
7. The Rest of the OWASP API Top 10
A complete API check should also cover: excessive data exposure (endpoints returning full objects where the UI shows one field — our PII classifier flags NID/passport/mobile/email-class responses), broken authentication, mass assignment (JSON fields the UI never sends but the API honors), rate limiting (unthrottled login and reset endpoints), and misconfigured CORS on API origins.
API Security Checklist (Print This)
- Full endpoint inventory, including shadow routes found in JS bundles and archives
- Method-by-method access control verified (not just GET)
- GraphQL introspection disabled in production; depth limits set; field-level auth tested
- gRPC reflection disabled on public services
- IDOR tested on every ID-accepting endpoint — ideally with two-session isolation proof
- Hidden-parameter fuzzing on all endpoints
- Rate limiting on authentication, reset, and expensive-query endpoints
- CORS on API origins reviewed: origins, credentials, and headers all deliberate
- Error responses standardized — no stack traces, no SQL fragments, no internal paths
Automate the Checklist
The 2MNY engine runs the full API family described above — shadow discovery, depth scanning against the OWASP API Top 10, verb-gap differential testing, GraphQL and gRPC probes, hidden parameter discovery, and IDOR surface mapping. Run a free scan to start, review every API scanner on the features page, or self-host the engine core (200 modules, Apache-2.0, no API keys) from GitHub.
Related reading: MCP Security: Auditing AI Agent Infrastructure · OWASP Top 10 Web Security Risks · What Is SQL Injection?
1 What should an API security checklist include?
Authentication and authorization on every endpoint, verb tampering checks (does your endpoint behave differently for GET vs POST vs PUT), mass-assignment protection, rate limiting, input validation, error handling that does not leak stack traces, CORS configuration, and documentation-drift detection where the live API differs from its OpenAPI spec. The full checklist is in the article.
2 What are shadow APIs?
Shadow APIs are endpoints that exist in production but are absent from documentation — old versions, internal endpoints, debug routes, or ones added under deadline pressure. They are dangerous because nobody updates, tests, or monitors them, yet they often handle sensitive data. Discovery scanning that enumerates real routes (not just documented ones) is the only reliable way to find them.
3 How do you test GraphQL and gRPC security?
For GraphQL: introspection exposure, overly deep queries (DoS), missing authorization on resolvers per-field, and mutation abuse. For gRPC: exposed reflection services, missing TLS, and unauthenticated method invocation. 2MNY ships dedicated GraphQL and gRPC-reflection scanner modules that probe exactly these patterns safely.
4 What is an API verb gap?
A verb gap is when an endpoint authorizes one HTTP method but a different method on the same path skips the check — a classic pattern is GET /admin/users being protected while HEAD or PUT on the same path is not. Scanners test each discovered path across the full verb set to surface these authorization asymmetries.
