API Security Testing: REST, GraphQL, gRPC, and the OWASP API Top 10

APIs surpassed traditional web pages as the dominant application attack surface around 2020. The shift was the predictable consequence of two parallel trends: the move from server-rendered monoliths to single-page front-ends with JSON back-ends, and the rise of microservices that talk to each other over the network. Where a 2010-era web application might have exposed twenty server-rendered URLs, the same business in 2026 routinely runs hundreds of API endpoints across mobile clients, web SPAs, partner integrations, and internal service-to-service traffic. The category of dedicated API security testing emerged because the previous generation of automated DAST scanners was built for stateless, link-following crawlers and was structurally unsuited to the stateful, schema-driven, authenticated workflows that modern APIs require.

This guide is the pillar reference for API security testing. It covers what makes the category distinct, the OWASP API Security Top 10 (2023) in full, the discovery problem that most programs underestimate, the difference between schema-based and behavioral testing, where source-level analysis like SAST fits, where dedicated runtime API security tools fit, the GraphQL and gRPC nuances that generic scanners miss, and how to sequence the adoption of these layers without drowning in false positives. The goal is education first: by the end you should be able to evaluate any API security tool on its merits, scope a program for your own surface, and articulate to a non-security stakeholder why API security is its own discipline rather than a footnote on the web application security program.

Why API Security Is Its Own Category

Most buyers come to this page looking for one of three things: api security scanning that runs continuously against a deployed API, api security scanners they can wire into CI to catch contract drift before merge, or a roadmap for picking among the api security testing tools listed in the vendor table later in this guide. All three are addressed below; the right combination depends on whether your priority is shifting findings as far left as the handler source, fuzzing against documented endpoints in the build, or analyzing live production traffic for behavioral anomalies.

For most of the 2000s and 2010s, application security and web application security were effectively synonymous. The dominant deployment pattern was a server-rendered web application with a small handful of HTML forms, a session cookie, and a relational database underneath. The OWASP Top 10, the major DAST scanners, the WAF rule sets, and the standard penetration test methodology were all designed around that pattern. Then microservices happened, mobile clients happened, single-page applications happened, and partner integrations happened — and the assumptions that held the category together quietly stopped holding.

The most visible change was the count. A monolithic web application might have exposed 20 to 50 routes that a human could enumerate by clicking around. A modern microservice estate routinely exposes hundreds or thousands of API endpoints across REST resources, GraphQL queries and mutations, gRPC service methods, webhooks, and event-driven message handlers. Manual enumeration is no longer feasible. The crawlers built into traditional DAST scanners were not designed for surfaces this large or this stateful, and even when an OpenAPI spec exists the scanner often does not know how to chain authenticated calls in the order the application expects.

The second change was schema enforcement. A 2010 web application took form input and let the server-side framework coerce it. A 2026 API exchanges JSON or binary payloads with explicit schemas that may or may not be enforced consistently between the gateway, the framework, and the handler. Mismatches between what the schema declares, what the framework validates, and what the handler trusts are a steady source of injection, type confusion, and access-control bypass bugs that no generic scanner catches without schema-awareness.

The third change was authentication. Session cookies were largely supplanted by OAuth 2.0 access tokens, OpenID Connect identity tokens, and JWT-based session systems with their own ecosystem of misconfigurations: weak signature algorithms, accepted "none" algorithms, leaky claim populations, missing audience checks, and confused-deputy problems between issuer and resource server. Each of these is invisible to a scanner that does not understand the token grammar.

The fourth and fifth changes were the proliferation of GraphQL — with its introspection endpoint, query depth attacks, and batching abuse — and the rise of gRPC, which speaks Protocol Buffers over HTTP/2 in a binary frame that most web scanners cannot even parse. Each of these protocols has its own attack surface that did not exist in the REST-and-cookies world, and each requires a tool that natively understands the wire format. That is the territory dedicated API security tooling occupies.

The OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 is the canonical reference for the vulnerability classes that matter for APIs specifically. The list was first published in 2019 and revised in 2023 to reflect the categories that the OWASP API Security Project saw most often in real-world incidents. It is meaningfully different from the classic OWASP Top 10 — several entries (BOLA, BFLA, BOPLA, the inventory and consumption items) have no real analog in the web-application list and reflect the unique structure of API surfaces. Every API security tool, AppSec leader, and developer working on APIs should be able to recite the list and recognize each pattern in code review.

• API1:2023 — Broken Object Level Authorization (BOLA). The handler accepts an object identifier from the request, fetches the object, and acts on it without checking whether the authenticated caller is permitted to access that specific object. Historically the most common and highest-impact API vulnerability class.
• API2:2023 — Broken Authentication. The authentication mechanism itself is implemented incorrectly, accepting weak credentials, mishandling tokens, allowing credential stuffing, or failing to invalidate compromised sessions.
• API3:2023 — Broken Object Property Level Authorization. The caller is permitted to read or write the object as a whole but should not be permitted to read or modify specific fields on it. Excessive data exposure (over-fetching) and mass assignment (over-writing) are the two named subcategories.
• API4:2023 — Unrestricted Resource Consumption. An endpoint accepts requests that consume excessive CPU, memory, bandwidth, third-party API quota, or money, without limits per caller, per IP, or per tenant.
• API5:2023 — Broken Function Level Authorization (BFLA). An endpoint that should be restricted to administrators or specific roles is accessible to ordinary users because the authorization check on the function itself is missing or implemented as a client-side restriction only.
• API6:2023 — Unrestricted Access to Sensitive Business Flows. A legitimate business workflow — purchase, signup, comment, password reset — is exposed without protection against automated abuse, allowing scalpers, scrapers, fraudsters, or spammers to consume the flow at scale.
• API7:2023 — Server Side Request Forgery (SSRF). An endpoint accepts a URL or hostname from the request and makes a server-side request to it, allowing the attacker to reach internal services, cloud metadata endpoints, or external systems through the API server.
• API8:2023 — Security Misconfiguration. The API stack is misconfigured in ways that expose risk: permissive CORS, unnecessary HTTP methods, verbose error messages, missing security headers, default credentials on management endpoints, or missing TLS on internal traffic.
• API9:2023 — Improper Inventory Management. The organization does not have a complete and accurate inventory of its APIs and their versions. Old versions, deprecated endpoints, and shadow APIs remain reachable in production and are often less hardened than current versions.
• API10:2023 — Unsafe Consumption of APIs. The API trusts data received from upstream third-party APIs as though it were trusted internal data, without validation, leading to injection, deserialization, or business-logic flaws driven by attacker-influenced upstream content.

Note the shape. More than half the list (API1, API3, API5, and arguably API2) is some flavor of authorization failure. This is the dominant API vulnerability class, and it is also the class that generic black-box scanners are weakest at finding, because correct authorization requires knowledge of business intent that the scanner does not have. Source-level analysis can identify the structural pattern (a handler that loads an object by request-supplied identifier without an authorization check between the load and the action), but proving exploitability typically requires either a tester with knowledge of the API or a runtime tool that observes real traffic.

API Discovery: The First Problem

Before anything can be tested it has to be known about, and most organizations are wrong about what APIs they actually run. The gap between the inventory the security team believes exists and the surface that is actually live in production is the single most underrated problem in API security. It is the entire reason API9:2023 (Improper Inventory Management) made the OWASP list.

Three patterns of unknown API repeatedly cause incidents. Shadow APIs are endpoints that exist in production but are not documented anywhere the security team can see them. They are written by developers, shipped through ordinary CI, and routed through the gateway without ever appearing in an OpenAPI spec or an architecture diagram. Zombie APIs are endpoints that were once part of a deprecated version, were supposed to be retired, and are still routed and reachable months or years later because nobody removed the route. They are particularly dangerous because the team that wrote them no longer maintains them and recent security improvements were not applied. Unmanaged third-party APIs are endpoints exposed by SaaS vendors, partners, or open-source components embedded in your deployment, that route through your perimeter but are not part of your inventory.

Discovery techniques fall into four families, each with characteristic strengths and gaps. Traffic mirroring taps the production gateway, mirrors a copy of every request to a discovery engine, and infers the live endpoint inventory from observed traffic. It catches every endpoint that is actually called, which is its strength and its weakness — endpoints that are routed but not currently exercised remain invisible until somebody hits them. OpenAPI and Swagger ingestion reads documentation that the engineering teams already maintain. It is fast and accurate where the documentation is current, and useless where the documentation has drifted. Code scanning derives the endpoint inventory from the source: every Express route, every Spring controller, every FastAPI router, every gRPC service definition. It finds endpoints that exist in code regardless of whether they are documented or currently called. Gateway and proxy log analysis reconstructs the inventory from access logs at the API gateway, the load balancer, or the service mesh. The most effective programs combine multiple sources rather than relying on any one in isolation.

Schema-Based vs Behavioral Testing

Active API testing splits cleanly into two philosophies, and the major dedicated API security vendors sit on one side or the other (or, more commonly in 2026, claim to do both with an emphasis that betrays their origin). Understanding which philosophy a tool actually implements is more important than the marketing differentiation between vendors.

Schema-based testing takes the API's specification — typically an OpenAPI document for REST, an SDL or schema introspection for GraphQL, a .proto file for gRPC — and uses it to drive a fuzzer. The fuzzer knows the legal request shape for every endpoint, generates valid and intentionally invalid variants, and checks that the server responds appropriately. Tools in this family include 42Crunch (which built its reputation on OpenAPI conformance and fuzzing), Postman with its API security tooling, APIsec, the open-source Schemathesis library, and the API-aware modes of StackHawk and Burp Suite. The value proposition is that schema-driven fuzzing is precise, reproducible, and integrates cleanly into CI as a contract-conformance check. The limitation is that it can only test what the schema declares; an endpoint not in the schema, or fields the handler accepts but the schema does not document, are invisible.

Behavioral testing instead observes real traffic, builds a baseline of what each endpoint normally looks like, and detects requests that deviate in ways that suggest abuse. This is the model behind Salt Security, Noname Security (acquired by Akamai), Traceable, Wallarm, and Cequence. The value proposition is that behavioral analysis catches what no schema-driven fuzzer can: novel attack patterns, business-logic abuse, account takeover sequences, scraping at scale. The limitation is that the system needs production traffic to learn from, the inevitable false positive rate against legitimate-but-anomalous behavior, and the inability to surface a bug before it ships because the tool only sees the deployed system.

Mature programs run both. Schema-based testing in CI catches contract drift and basic injection before deployment. Behavioral testing in production catches what schema-based testing structurally cannot. They are not substitutes; they cover different bug populations.

Where SAST Fits in API Security

APIs are implemented in code. Every REST endpoint, every GraphQL resolver, every gRPC service method is a function in some language that handles an incoming request and produces a response. That handler code is exactly what static application security testing analyzes. SAST is not an API security platform — it does not perform runtime discovery, schema fuzzing, or traffic-based behavioral analysis — but it is the lifecycle-earliest layer for many of the bug classes the OWASP API Security Top 10 enumerates, because those bugs live in the handler source long before they reach a runtime detector.

A mature SAST engine analyzing API handler code can identify a missing authorization check between the moment a handler loads an object by a request-supplied identifier and the moment it acts on that object — the structural pattern behind API1 (BOLA) and API3 (BOPLA). It can flag a function-level authorization gap where a handler that should be admin-only is registered without the role guard — the API5 (BFLA) pattern. It can trace a SQL injection sink reachable from a request parameter through interprocedural data flow, even when the dangerous sink lives several call frames away from the endpoint. It can identify an SSRF where a webhook handler accepts a URL from the request and makes an outbound HTTP call without an allowlist (API7). It can flag hardcoded credentials in API client code and weak cryptography in token signing.

GraphNode SAST performs interprocedural data flow analysis across 13+ languages and 780+ security rules covering common vulnerability classes including the OWASP Top 10 and CWE Top 25. For API codebases that means the same data flow engine that traces taint through a server-rendered application also traces it through Express routes, Spring controllers, ASP.NET Core actions, FastAPI handlers, gRPC service implementations, and GraphQL resolvers — wherever the framework registers a handler, the analyzer follows the data flow into and through it. This is the honest claim: GraphNode is a SAST and SCA platform that analyzes API handler source code, surfacing a meaningful subset of API security bugs at the source-code level. It is not a substitute for a dedicated API security platform that handles runtime discovery, schema fuzzing, and traffic-based behavioral analysis. It is the foundation layer beneath those platforms.

Where DAST and Dedicated API Tools Fit

Source-level analysis is necessary but not sufficient for API security. The deployed API has its own attack surface that is invisible from source: the gateway configuration, the WAF rules, the rate limits, the actual auth provider response under attack, the network policies between services, the contract drift between what the spec declares and what the handler accepts. That is where runtime testing — dynamic application security testing in the broad sense, and dedicated API security platforms in the narrow sense — provides coverage that no source scanner can.

Generic DAST scanners with API support and the dedicated API security category overlap considerably; the practical distinction is usually whether the tool was built for HTML applications and added APIs as a capability, or built for APIs and approaches the problem natively. The table below summarizes the most commonly evaluated tools. Capability claims are limited to what each vendor publicly documents; coverage of any specific scenario will vary by version and configuration.

Choosing between these tools is rarely about a feature checklist. It is about how the tool fits into the surface you actually run: whether it speaks the protocols your APIs use natively (REST, GraphQL, gRPC, async messaging), how it handles your auth provider, how its findings flow into your bug tracker, and what the false positive rate looks like against your traffic, not someone else's. Always run a proof of concept against representative APIs before signing.

GraphQL and gRPC Security

Two protocols deserve their own treatment because generic API security tooling routinely misses what makes them distinct.

GraphQL consolidates many endpoints behind a single URL and exposes the entire schema through a built-in introspection query. The convenience that makes GraphQL pleasant for developers is also its first attack surface. Introspection exposure in production means an attacker can query the schema directly and learn every type, field, and resolver the server supports — useful intelligence for crafting follow-on attacks. Query depth and complexity attacks exploit the fact that GraphQL queries can be arbitrarily nested; a single 30-line query can fan out into millions of database operations if depth and complexity limits are not enforced. Batching attacks exploit the GraphQL batching feature: a single HTTP request can contain hundreds of operations, sidestepping per-request rate limits. Field-level authorization is harder than endpoint-level authorization, because every field on every type is potentially sensitive and the resolver layer must enforce access control at every leaf. None of these patterns map cleanly onto the OWASP API Top 10 categorization, which is one reason GraphQL deserves explicit attention.

gRPC speaks Protocol Buffers over HTTP/2 in binary frames. Most generic web scanners cannot parse the wire format at all, which means a perimeter scanner pointed at a gRPC endpoint reports nothing — not because nothing is wrong, but because the scanner cannot read the traffic. Effective gRPC security testing requires tooling that understands the .proto schema and can construct binary payloads accordingly. Reflection metadata, the gRPC analog of GraphQL introspection, exposes the service definitions to anyone who calls the reflection API and is similarly something that should be disabled in production for sensitive services. Streaming RPCs add their own resource-consumption considerations because a long-lived bidirectional stream behaves very differently from a request-response endpoint under abuse. The dedicated API security platforms that support gRPC do so by ingesting .proto files explicitly; treating gRPC like just-another-HTTP service produces neither coverage nor confidence.

Building a Practical API Security Program

A pragmatic adoption sequence reflects both the cost of each layer and where it fits in the lifecycle. The order in which capabilities are added matters more than the absolute coverage at any given moment.

Start with SAST in CI for API handler code. Every push runs static analysis against the handler source: REST routes, GraphQL resolvers, gRPC service implementations. Critical-severity new findings (BOLA-class missing-authorization patterns, injection sinks, hardcoded secrets, weak cryptography) fail the build; existing findings are visible but not blocking. This is the lifecycle-earliest signal and the cheapest place to fix issues.

Ingest OpenAPI specs into a fuzzer. Wherever the team already maintains OpenAPI documentation — and most modern API teams do — point a schema-driven fuzzer at it as part of the pipeline. The fuzzer catches contract drift, type confusion, and basic injection on documented endpoints. Tools in this family integrate cleanly into CI and produce reproducible findings tied to specific operations.

Add a runtime API gateway with rate limiting and basic protection. A managed gateway (Kong, Apigee, AWS API Gateway, Azure API Management) provides per-caller and per-endpoint rate limiting, request validation against the OpenAPI spec, and a single chokepoint for adding headers, logging, and JWT verification. This addresses API4 (Unrestricted Resource Consumption) and API6 (Sensitive Business Flow abuse) at the perimeter without requiring application-level changes.

Add a dedicated API security platform when scale justifies it. Once the surface area exceeds what schema-based testing and gateway controls can cover — typically when there are hundreds of endpoints, multiple teams shipping independently, and significant production traffic — a behavioral runtime platform earns its license cost. The platforms in the vendor table above all serve this layer with different emphases.

Frequently Asked Questions

What is API security testing?

API security testing is the discipline of finding and fixing security vulnerabilities specific to application programming interfaces — REST, GraphQL, gRPC, webhooks, and event-driven endpoints — across the development lifecycle. It covers four main problems: discovering every API the organization actually runs, validating that each endpoint accepts only well-formed input that conforms to its declared schema, verifying that authentication and authorization are correctly enforced at both the function and the object level, and detecting runtime abuse of legitimate endpoints. The canonical reference for the vulnerability classes that matter is the OWASP API Security Top 10 (2023), which is meaningfully different from the classic OWASP Top 10 because the API attack surface has its own structural patterns.

What is the difference between API security and web application security?

Web application security historically focused on server-rendered web applications with HTML forms, session cookies, and a small handful of routes a human could enumerate. API security covers a different surface: hundreds or thousands of programmatic endpoints, schemas that may or may not be enforced consistently between the gateway and the handler, modern token-based authentication (OAuth, OpenID Connect, JWT) with its own ecosystem of misconfigurations, and protocols beyond HTML — GraphQL with its introspection and depth-attack surface, gRPC with its binary wire format. The OWASP API Security Top 10 reflects this difference; categories like BOLA, BFLA, BOPLA, and Improper Inventory Management have no direct analog in the classic web application Top 10.

Is OWASP API Security Top 10 different from OWASP Top 10?

Yes, they are two different lists maintained by different OWASP projects. The classic OWASP Top 10 (the most recent edition is 2021 with the 2025 release in progress) covers web application security broadly: injection, broken access control, cryptographic failures, insecure design, vulnerable components, and so on. The OWASP API Security Top 10 (2023 edition) is focused specifically on API attack surfaces and includes categories that do not appear in the web list: BOLA (API1), BFLA (API5), Object Property Level Authorization (API3), Unrestricted Access to Sensitive Business Flows (API6), Improper Inventory Management (API9), and Unsafe Consumption of APIs (API10). A team building APIs should treat the API Security Top 10 as the primary reference and the classic Top 10 as supplementary.

Do I need a dedicated API security platform?

It depends on the scale and risk of the API surface. Small teams with a handful of well-documented APIs can get meaningful coverage from SAST in CI for the handler code, schema-based fuzzing against the OpenAPI specs, a managed gateway for rate limiting and request validation, and periodic external pen testing. Once the surface grows beyond what schema-based testing can cover — typically hundreds of endpoints across multiple teams shipping independently, with significant production traffic and partner integrations — the behavioral runtime analysis that dedicated API security platforms (Salt, Noname/Akamai, Traceable, Wallarm, Cequence) provide is hard to replicate with general-purpose tooling. The decision is usually about scale, not about a binary need.

Can SAST find API security bugs?

Yes, for a meaningful subset of the OWASP API Security Top 10. Static analysis of API handler source code can identify the structural patterns behind BOLA (a handler that loads an object by request-supplied identifier without an authorization check between the load and the action), BFLA (a handler that should be admin-only registered without the role guard), injection sinks reachable from request parameters, SSRF in webhook implementations, hardcoded credentials, and weak cryptography in token handling. SAST is not a substitute for dedicated API security testing — it does not perform runtime discovery, schema fuzzing, or traffic-based behavioral analysis — but it is the lifecycle-earliest layer for the bug classes that live in the handler source. GraphNode SAST performs interprocedural data flow analysis across 13+ languages and 780+ security rules, which means the same engine that traces taint through a server-rendered application also traces it through Express routes, Spring controllers, ASP.NET Core actions, FastAPI handlers, gRPC service implementations, and GraphQL resolvers.