Security · Topic 28 of 28 · Part V — Specialized assessment targets

API testing

Modern applications are APIs. The frontend is a thin client; authorization, data, and business logic live in the API layer — and that is where the risk lives.

Syllabus: § Assessment of Applications → API-specific assessment

Topic 28 · API assessment

The API is the application.

By the end of this topic you can:

Distinguish API testing from web-application testing and scope it accordingly
Discover and enumerate REST, GraphQL, and gRPC endpoints when documentation is incomplete
Test for the OWASP API Security Top 10 classes — especially BOLA, BFLA, broken authentication, mass assignment
Reason about authentication and authorization at the API layer (API keys, OAuth, JWT, mTLS)
Recognize the failure modes of API gateways, rate limits, and WAFs
Produce findings developers can fix at the design level, not just at the request level

How API testing differs from web testing

Discovery

No HTML links to crawl. Endpoints come from documentation (OpenAPI, GraphQL introspection), traffic capture, source code, or wordlist probing.

Authorization model

Per-endpoint, per-object — not per-page. Every request is independent and must be authorized on its own merits.

Tokens, not sessions

Bearer tokens (often JWTs), API keys, OAuth flows, mTLS. The token's contents and lifecycle matter as much as the request.

The API is the truth

"The frontend hides this button" is not a control. The same API is reachable from a mobile app, a partner integration, or a raw curl.

Schema as contract

OpenAPI / Swagger / GraphQL schema files are attack input (telling the tester what exists) and a defensive artefact when enforced server-side.

Versioning is real

v1 and v2 often coexist with different security postures. Both are in scope.

Discovery: finding endpoints without a map

OpenAPI / Swagger: /openapi.json, /swagger.json, /v1/api-docs, /redoc — sometimes leaked accidentally
GraphQL introspection: POST to the endpoint with the introspection query — reveals the full schema unless explicitly disabled
Client traffic capture: intercept the web or mobile client; enumerate every endpoint it calls (Burp Suite, mitmproxy, Frida for mobile)
Source code review: bundled JS in production reveals endpoint paths and parameter names
Wordlist enumeration: ffuf / feroxbuster with API-specific wordlists (/api/v1/, /internal/, /v2/)
Mobile reverse engineering: APK / IPA static analysis reveals base URLs and auth patterns
Cloud assets: API Gateway resources, Cloud Function HTTP triggers, Kubernetes ingress objects

Discipline For every endpoint observed in the client, request it directly with varied parameters. For every parameter, vary its shape. For every response, examine what was returned but not consumed by the client.

OWASP API Security Top 10 (2023) — access control

API1 — BOLA Broken Object Level Authorization. An endpoint accepts an object ID and returns the object without verifying ownership. Test: enumerate IDs, substitute another user's ID, observe the response. The dominant API vulnerability class.

API3 — Broken Object Property Level Auth Combines mass assignment (sending is_admin: true on an update) with excessive data exposure (reading other users' private fields in responses).

API5 — BFLA Broken Function Level Authorization. Privileged endpoints accessible to non-privileged users. Common pattern: the UI hides them; the API does not enforce the restriction.

API2 — Broken Authentication Weak token issuance, insecure password reset, missing rate-limit on login. Test: JWT none-algorithm, weak HMAC secrets, predictable tokens, account enumeration via error messages.

OWASP API Security Top 10 (2023) — resource & infrastructure

API4 — Unrestricted Resource Consumption No rate limit, no resource cap, no pagination cap, no input-size cap. Test: large requests, deep pagination, parallel request floods. Look for 429 responses and timeout behaviour.

API6 — Unrestricted Access to Sensitive Business Flows Business operations (purchasing, voting, refunding) reachable without workflow constraints. Test: replay the flow programmatically; observe whether anti-automation controls intervene.

API7 — SSRF An API takes a URL parameter and fetches it server-side. Provide internal targets: cloud metadata, localhost, internal services.

API8 — Security Misconfiguration TLS, headers, CORS, debug endpoints, default credentials, verbose errors.

API9 — Improper Inventory Management Old API versions still online; staging endpoints exposed. Test: enumerate versions; try the same vulnerability against each.

API10 — Unsafe Consumption of APIs An API trusts responses from upstream APIs. When accessible, manipulate the upstream and observe consumer behaviour.

These categories are a taxonomy for organising findings — not a sequential workflow for executing tests.

Authentication mechanisms: JWT in depth

JWT is the most attack-rich authentication artefact in API testing. A correctly-implemented system validates all of these:

Algorithm pinned: reject alg: none; reject algorithm changes in the header
Algorithm confusion: HS256 accepted with the public RSA key as HMAC secret — crackable or forgeable
Weak HMAC secret: cracked offline with hashcat -m 16500
kid / jku / x5u injection: kid pointing to attacker-controlled file; jku pointing to attacker-controlled key URL
Missing claims validation: no expiration check, no audience check, no issuer check
Stateless logout: "logout" is meaningful only with token introspection or short lifetimes + refresh rotation

Other mechanisms API keys: static secrets — where stored, can they be exfiltrated, are they rotated?
Basic auth: acceptable over TLS for server-to-server; otherwise a finding.
mTLS: test certificate revocation, CA hierarchy, client-side pinning bypass.

Tools jwt_tool, Burp JWT Editor

OAuth 2.0 and OIDC testing

Common OAuth misconfigurations

No PKCE on public clients using the authorization-code flow
Implicit flow still in use (deprecated; token in URL fragment)
Open redirector in redirect URI — token theft via crafted URI
State parameter not validated — CSRF on the authorization endpoint
Scope creep — clients request broad scopes; users grant without understanding
Refresh-token reuse without rotation — allows long-term impersonation
Confused-deputy — one OAuth client shared across multiple applications

Key insight OAuth is a protocol, not a security control. Correctly implemented it protects delegated authorization; incorrectly implemented it creates new attack surface.

Testing approach: intercept the real client in traffic; replay the authorization-code flow; probe each step with modified parameters.

Tools: oauth.tools, Postman; intercept the real client for production testing.

Authorization at the API layer

The structural failure: an authorization check that should run on every request fails to run on some.

Systematic approach

1For every endpoint, retry with no token — observe 401 vs 200

2Retry with a low-privileged token — compare response body and status

3Retry with a different user's token — compare response body and status

4Identify IDs flowing through endpoints; substitute another user's IDs

Look for inconsistency GET /api/v1/users/{id} may authorize correctly; GET /api/v1/users/{id}/preferences may not. Sub-resources are a classic gap.

Tools Burp's Autorize / AuthMatrix automate multi-account comparison. For 200 endpoints, scripted comparison tests are the only practical approach.

GraphQL-specific testing

Introspection: if enabled in production, the full schema is revealed — every type, field, mutation
Depth attacks: deeply nested queries can exhaust resources via recursive fragment expansion
Alias-based amplification: many aliased copies of the same expensive query in one request
Field-level authorization: each field has its own resolver; some may not check authorization independently
Batching: some implementations support query batching — abuse patterns differ from single-query flows
Mutations: the dangerous-function equivalent — DELETE and UPDATE analogues; test the same auth controls as REST write operations

Introspection disabled? Clairvoyance probes field names via error messages — partial schema recovery is still possible from a hardened endpoint.

WAF blind spot All GraphQL operations are POST to the same endpoint. WAF rules tuned for REST URL patterns miss GraphQL entirely. Logging that captures URLs but not bodies loses all operation context.

Tools: graphql-cop, clairvoyance, InQL, Burp GraphQL extensions.

gRPC, Protobuf, and event-driven APIs

gRPC / Protobuf

Server reflection: equivalent of GraphQL introspection; enumerable if enabled
Tools for manual testing: grpcurl, evans, Postman (recent versions)
Field manipulation: send fields outside the declared schema; send unexpected types
Streaming endpoints: bidirectional streams have their own concurrency and resource concerns

The transport (HTTP/2 + protobuf) does not change the underlying authorization or business-logic risks — only the discovery problem is harder.

WebSockets and event-driven

Authentication at connection time only: messages on an established connection may not be re-authorized per message
Per-message authorization: implementations often only authenticate at the handshake; authorization per message is frequently missing
Cross-origin WebSocket hijacking: misconfigured servers accept connections from unintended origins

Tools: Burp WebSocket support, websocat.

API gateways, rate limits, and WAFs

API gateway misconfigurations

Rate limit per IP behind NAT — trivially defeated
Rate limit set high enough to be ineffective in practice
Schema validation in non-blocking (logging-only) mode
Authentication on the gateway; backend directly reachable — gateway bypass

Platforms: Kong, AWS API Gateway, Azure API Management, Apigee, Tyk.

WAF limitations

Rule coverage for API patterns (GraphQL, JSON bodies) is uneven
Bypass via parameter pollution, encoding, content-type tricks
Blocks SQLi payloads ≠ backend is hardened against SQLi

Key finding pattern If the gateway enforces auth and rate limits but the backend is also directly reachable (e.g., an ALB without IP allowlisting), the entire gateway layer is bypassed.

Methodology: a typical API engagement

1Scope — endpoints, versions, environments, auth mechanisms, in-scope business flows

2Discovery — docs, traffic capture, source review, wordlists, introspection

3Auth assessment — token issuance, JWT structure, OAuth flows, mTLS

4Per-endpoint authorization — BOLA, BFLA across the surface

5Object-property authorization — mass assignment, excessive data exposure

6Business-logic flows — multi-step abuses, anti-automation

7Resource limits — rate limits, payload sizes, pagination

8GraphQL / gRPC specifics where applicable

9Gateway / WAF effectiveness — gap finding and mitigation validation

10Inventory & version hygiene — old versions, leaked staging endpoints

11Reporting — by category and by endpoint; design-level remediation

Tooling overview

Category	Tools
Interception / proxy	Burp Suite Professional (with API extensions), mitmproxy, OWASP ZAP, Caido
API-aware fuzzing	ffuf, Burp Intruder, Postman + Newman (scripted), kiterunner (content discovery)
JWT	jwt_tool, Burp JWT Editor
GraphQL	graphql-cop, clairvoyance, InQL, Burp GraphQL extensions
gRPC	grpcurl, evans, Postman gRPC
OpenAPI-driven	42Crunch (commercial), Spectral (linting), Schemathesis (property-based)
OAuth	oauth.tools, Postman; intercept the real client for production
Auth comparison	Burp Autorize, Burp AuthMatrix
WebSocket	Burp WebSocket support, websocat

Check — systematic BOLA testing

Reflection

A REST API has 200 endpoints. You have a low-privileged test account. How do you systematically test for BOLA across the surface — without 200 individual manual tests?

Reveal answer

Identify endpoint patterns from documentation or traffic. For each pattern, locate the object ID parameter. Script a comparison test: vary only the ID across two accounts and record the response. Rank by response divergence — identical responses indicate a possible BOLA. Manually inspect divergent cases. Tools like Autorize / AuthMatrix automate the multi-account comparison and flag discrepancies automatically.

What you take home

API testing is not web testing minus HTML — discovery, authorization, and the vulnerability mix are fundamentally different
BOLA (API1) is the dominant class; every object ID in every endpoint is a BOLA candidate
BFLA (API5) is the privilege-escalation sibling: the UI hides it; the API must enforce it
JWT correctness requires validating algorithm, signature, issuer, audience, expiration, and revocation
OAuth is a protocol; each step in the flow (code exchange, state, redirect URI) is a potential misconfiguration
A gateway that enforces auth, with a directly-reachable backend, enforces nothing
The most valuable API assessment deliverable is often the inventory: old versions, shadow endpoints, forgotten integrations

Master the API layer and you master the most consequential attack surface in modern application security.

END · TOPIC 28

Test the API. Not the button.

Review the OWASP API Security Top 10 (2023) and map each category to an endpoint in an API you have access to.