API Security: A Buyer's Guide to Testing REST, GraphQL, and gRPC

Who this is for

You're evaluating API security testing vendors or planning your first API pentest. This guide walks through what distinguishes a real assessment from automated scanner output with a cover page. We've audited API-heavy applications ranging from fintech payment platforms to internal admin services, and the patterns are consistent.

1. Why API testing is different from web app testing

A web app pentest focuses on browser interactions — form inputs, cookies, session management, DOM-based XSS. An API pentest is authentication, authorization, rate limiting, and business logic. The attack surface is different.

APIs don't have a "first page" to crawl. They have endpoints that accept structured requests and return structured responses. The tester needs to know the API shape — either via OpenAPI/Swagger documentation, captured traffic, or reverse engineering from client code.

Most API vulnerabilities are not about input validation in the way SQLi and XSS are. They're about who can call what and what happens when they do. This requires knowledge of your business model.

2. OWASP API Security Top 10 (2023) — the ones that actually matter

The OWASP API Security Top 10 lists the most common API vulnerabilities. In practice, we see five of them repeatedly:

• API1: BOLA (Broken Object Level Authorization). You can request another user's resource by guessing or incrementing their ID. This is #1 for a reason.
• API2: Broken Authentication. Weak token validation, missing auth checks, hardcoded credentials, or JWT signing issues. Less common than BOLA but usually critical.
• API3: Broken Object Property Level Authorization. A response includes fields you shouldn't see (internal IDs, PII, sensitive flags). Related to BOLA but at the property level.
• API4: Unrestricted Resource Consumption. No rate limiting, pagination limits, or request size caps. Leads to DoS or data exfiltration.
• API5: Broken Function Level Authorization. You can call admin endpoints without admin rights. Often baked into the application layer, not a network-level check.

The others (mass assignment, unsafe deserialization, injection) are real but less frequent in modern APIs. A good assessment spends time on the top five.

3. Authentication and authorization testing

Authentication is "who are you?" Authorization is "what can you do?" They're often conflated, but a tester needs to check both.

For token-based authentication (JWT, OAuth2), the tester should:

• Verify the token signature. A JWT with alg: "none" or an unsigned token is a red flag.
• Check token expiry and refresh token handling.
• Test whether the API validates the token on every request or caches validation.
• Verify that modifying the token payload (changing user ID, role, or claims) is detected.

$ curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI5OTkiLCJyb2xlIjoiYWRtaW4ifQ.signature" \
  https://api.example.com/users/1/profile

# If you can change the "sub" to another user ID and access their profile, that's BOLA

For API keys, verify that keys are not logged in server-side request logs, not sent in query strings (they appear in referrer headers and logs), and not stored in client code.

4. BOLA / IDOR — the #1 API vulnerability

BOLA is the single most common high-severity finding in API pentests. We find it in roughly 7 out of 10 engagements. The pattern is always the same: you request a resource by ID, and the server returns it if the user is authenticated, never checking if the user owns or should see that resource.

A simple test:

$ curl -H "Authorization: Bearer $TOKEN1" https://api.example.com/invoices/42
{
  "id": 42,
  "amount": 1200,
  "customer_id": 100,
  "line_items": [...]
}

# Now try another user's token
$ curl -H "Authorization: Bearer $TOKEN2" https://api.example.com/invoices/42
# If you get the same response, that's BOLA

What we see in the field: teams fix BOLA in the happy path (the resource list endpoint) but miss it in related endpoints. An invoice-by-ID endpoint is protected, but the invoice-PDF endpoint accepts the same ID with no auth check. An order endpoint is protected, but the shipment-tracking endpoint that references the order is not.

The fix is boring: on every endpoint that returns a resource, query the resource and verify the current user has access before returning it. Do this in a middleware or a utility function that can be reused across all endpoints.

5. GraphQL-specific testing

GraphQL has a different threat model than REST. Introspection allows clients to query the API schema and discover all available queries, mutations, and types. If introspection is enabled in production, an attacker can map your entire API surface.

$ curl -X POST https://api.example.com/graphql \
  -H "Content-Type: application/json" \
  -d "{\"query\": \"query{__schema{types{name}}}\"}"
# Lists all types in the schema

Disable introspection in production. Check your GraphQL server configuration (Apollo Server, Relay, graphene, etc.) for the setting. It's usually a one-line flag.

GraphQL also enables query batching and aliasing. An attacker can send multiple queries in a single request:

{
  user1: user(id: 1) {  id name email }
  user2: user(id: 2) {  id name email }
  user3: user(id: 3) {  id name email }
  ...
} 

This can bypass rate limiting that counts requests, not queries. Combine this with deeply nested queries and you have a DoS vector.

A good assessment includes depth limiting (rejecting queries deeper than X nesting levels) and query complexity scoring.

6. gRPC and protobuf testing

gRPC APIs use protocol buffers for serialization and HTTP/2 for transport. They're binary, not JSON, which makes them harder to test with curl. Use grpcurl to interact with gRPC services.

$ grpcurl -plaintext localhost:5000 list
# Lists all services

The same BOLA and authentication patterns apply. A common trap: gRPC services are often deployed on an internal network and assumed to be trusted. But if the service is accessible from the Internet or from untrusted clients, the same authorization checks are needed.

Protobuf definitions can sometimes be extracted from binaries or discovered via reflection. Once you have the .proto definition, you can generate client code and test the service systematically.

7. Rate limiting and business logic

Rate limiting protects an API from being hammered. But most implementations are incomplete. A tester should verify:

• Rate limits are per-user, not per-endpoint. One endpoint with no limit can be abused even if others are protected.
• The limit applies to both successful and failed requests. An attacker can't brute-force a password by hitting the endpoint 10,000 times if 9,999 fail.
• Limits reset predictably and are not resettable by the user (e.g., via logging out and back in).
• Pagination limits exist. An API that returns 10,000 records per request can be abused to exfiltrate data or cause resource exhaustion.

Business logic testing is the least automatable part of API security. It requires understanding what the API is supposed to do and what shouldn't be possible. A payment API shouldn't allow you to refund an order you didn't place. An inventory API shouldn't let you oversell stock. These checks are application-specific.

8. What to expect in the report and what to fix first

A real API security report should include:

• A summary of the API shape (endpoints, methods, key parameters).
• For each vulnerability: the endpoint, the test case, the request/response showing the issue, and the impact.
• Severity ratings (CVSS is overkill for APIs; focus on impact).
• Specific remediation advice, not generic guidance.

Most reports from other firms are automated scanner output with a cover page. You'll see 50+ low-severity findings ("missing HTTP headers") padded with noise. A focused assessment returns 5–10 findings, most high-severity, with specific reproduction steps.

Fix in this order:

1. BOLA and broken authentication (critical).
2. Broken function-level authorization (critical).
3. Unrestricted resource consumption / rate limiting (high).
4. Broken property-level authorization / information disclosure (high).
5. Everything else (medium and below).

If an assessment doesn't find BOLA or broken auth, either your API is exceptionally well-built or the assessment was shallow.

The short version

API security is about authentication, authorization, and rate limiting—not input validation. Insist on an assessment that covers BOLA, broken function-level auth, and business logic testing. Disable GraphQL introspection in production and implement depth limiting on complex queries. Test that every endpoint validates the authenticated user has permission to access the requested resource. Verify rate limits are per-user and apply to failed requests. Expect a focused report with 5–10 findings, mostly high-severity, with exact reproduction steps. Ignore reports padded with 50+ low-severity findings about missing headers. If the assessment doesn't find BOLA, it wasn't thorough.