OWASP API Security Top 10 Testing Guide

Direct answer: Use the OWASP API Security Top 10 as a coverage map, not a ten-payload scan. First inventory the API you actually operate, create authorized identities and owned data fixtures, define safe limits, and then map repeatable tests to API1 through API10. A finding is complete only when you can show the request context, expected rule, observed response and side effect, root cause, corrected behavior, and a regression test.

This guide uses the OWASP API Security Top 10:2023, which remains the current edition shown by the project as of October 13, 2026. It is not a “2026 edition.” OWASP also explains that the list is an awareness document, not a substitute for your own risk analysis. Its category order does not tell you which defect is reachable in your environment or which failure creates the greatest business consequence.

No live API, account, token, tenant, repository, gateway, scanner, service mesh, third-party service, or production control was tested for this article. Test only systems you own or are explicitly authorized to assess. Do not perform production denial-of-service, credential stuffing, destructive state changes, uncontrolled outbound requests, or costly resource-exhaustion tests.

Start with a test charter, not a scanner

An API test can change data, trigger messages, consume paid services, create support cases, or reach downstream systems. Before sending a request, record the target hosts and versions, allowed identities, permitted methods, test window, source addresses, data classification, traffic ceiling, cost ceiling, cleanup method, monitoring owner, emergency contact, and stop conditions. Separate production from test environments and name any production-safe checks explicitly.

Define what proof will count. A 403 response can still be a failure if the API changed a record before returning it, queued a job, sent an email, charged an account, or disclosed sensitive fields in the body. Conversely, a 200 response may be correct for a public resource. The expected authorization and state transition must be written before the observation can be judged.

The test charter should also identify secrets and evidence that must not enter tickets or screenshots. Preserve request identifiers, sanitized request shapes, role and tenant labels, response status and field sets, before-and-after state, relevant logs, and timestamps. Do not retain bearer tokens, credentials, personal data, internal addresses, or exploit details beyond the approved evidence boundary.

Build the real API inventory

The first technical task is to reconcile the declared surface with the operating surface. The OWASP Web Security Testing Guide API reconnaissance page recommends finding documented and undocumented endpoints and parameters, requesting machine-readable definitions, and exercising the application with accounts at different privilege levels. That page is useful current development guidance; it is not presented here as a stable numbered acceptance standard.

Collect OpenAPI or legacy Swagger definitions, GraphQL schemas or exported schemas, gRPC service definitions, request collections, gateway routes, service-mesh configuration, client traffic, mobile application calls, partner documentation, webhook definitions, background-worker integrations, and DNS or host inventories. Record the environment, host, base path, protocol, version, owner, data handled, client, identity mechanism, upstream and downstream dependency, deployment artifact, and last observed request.

Then compare sources. A route in a specification may not be deployed. A deployed legacy version may be absent from current documentation. A gateway may expose a path that the service owner thinks is internal. A mobile client may still call a deprecated endpoint. API9 is not solved by owning a spreadsheet; it is solved when declared, deployed, and observed surfaces agree and stale routes have an owner and retirement decision.

Create fixtures that make policy testable

Build a small controlled fixture set. At minimum, use an unauthenticated context; two users with the same role but different object ownership; users in different tenants; a lower-privilege and higher-privilege user; a service identity; objects owned by each identity; sensitive and ordinary properties; ordinary and administrative functions; and a business flow with valid and invalid states. Add expired, revoked, wrong-audience, and wrong-scope tokens where the identity system supports safe test issuance.

Write the expected result for each combination of subject, action, object, field, and context. The context may include tenant, workflow state, time, device, region, channel, or risk signal. EncryptCentral’s broken access control testing checklist provides the deeper role-and-resource matrix. Reuse that matrix rather than improvising object identifiers during a live test.

For every case, capture both an allow path and a deny path. The allow path proves that a proposed fix did not break intended use. The deny path proves that the policy is enforced at the API, not merely hidden by a client. Use owned test objects and reversible actions. If a test would contact a real person, charge money, allocate scarce capacity, or make an irreversible change, replace it with a stub, sandbox, or approved simulation.

Map safe tests to API1 through API10

OWASP category	Controlled test question	Evidence to retain
API1: Broken Object Level Authorization	Can identity A read, change, delete, link, export, or act on identity B’s owned object by changing an identifier in the path, query, header, or body?	Owner matrix, request location of the identifier, before-and-after object state, and allow/deny comparison.
API2: Broken Authentication	Do every login, recovery, enrollment, refresh, logout, and service-authentication flow validate credentials and tokens, limit abuse, revoke access, and require fresh proof for sensitive changes?	Flow inventory, token claim expectations, attempt limits, revocation result, reauthentication result, and sanitized identity logs.
API3: Broken Object Property Level Authorization	Can a lower-privilege caller read a hidden sensitive property or write a protected property by adding, renaming, nesting, or nulling fields?	Schema, permitted field set by role, raw response keys, submitted field set, and saved object read-back.
API4: Unrestricted Resource Consumption	Are time, payload, pagination, batch, file, concurrency, recursion, downstream-call, and paid-action limits enforced safely?	Approved ceiling, small boundary tests, 429 or other designed behavior, resource telemetry, cost guardrail, and recovery.
API5: Broken Function Level Authorization	Can a user call an administrative or higher-privilege function by changing the route, method, content type, API version, or operation name?	Function-role matrix, method and route, intended privilege, response, side effects, and policy-decision log.
API6: Unrestricted Access to Sensitive Business Flows	Can an authorized function be automated in a way that abuses inventory, reservations, voting, comments, referrals, promotions, recovery, or another valuable process?	Business invariant, per-actor and global limits, sequence, velocity, duplicate handling, outcome, and alert route.
API7: Server-Side Request Forgery	Can a URL-accepting feature reach an unapproved destination, scheme, redirect target, internal range, or metadata service?	Allowlisted test receiver, normalized destination, redirect decision, DNS and egress evidence, timeout, and blocked-result log.
API8: Security Misconfiguration	Do alternate hosts, versions, errors, debug routes, CORS, methods, content types, TLS, caches, gateways, and service defaults match the approved baseline?	Versioned baseline, effective saved state, external behavior, exception, and drift result.
API9: Improper Inventory Management	Do specification, gateway, deployment, client, and observed traffic inventories agree, including deprecated and non-production versions?	Reconciled endpoint list, owner, version, data class, last use, exposure, retirement decision, and residual mismatch.
API10: Unsafe Consumption of APIs	Does the service distrust downstream data, constrain destinations and redirects, verify transport, validate responses, and enforce time, size, and resource limits?	Integration contract, allowed destinations, sanitized response fixtures, failure behavior, resource limits, and downstream telemetry.

The categories overlap. One request may expose an object-level authorization defect, an excessive property, and an undocumented legacy version. Record the primary root cause and related coverage instead of inflating one defect into several disconnected tickets.

For API8, use EncryptCentral’s security misconfiguration checklist to move from a versioned baseline through drift detection, controlled remediation, operating-state read-back, and retained regression evidence.

Run each test as an evidence-producing experiment

1. Name the rule. Identify the contract, policy, schema, business invariant, or baseline that defines expected behavior.
2. Record the precondition. Note the environment, deployment version, identity, tenant, owned fixture, object state, and relevant configuration.
3. Send the smallest safe variation. Change one dimension—object, property, role, method, sequence, limit, destination, or version—so the result can be explained.
4. Observe more than the HTTP status. Compare response fields, headers, timing, saved state, queued work, messages, billing, logs, metrics, and downstream calls.
5. Repeat the control. Run the intended allow case and the intended deny case under the same deployment.
6. Classify the result. Separate confirmed defects, expected behavior, approved exceptions, test-data errors, tool heuristics, and unresolved observations.

The OWASP REST Security Cheat Sheet is a useful cross-check for transport, endpoint-level access control, method restrictions, workflow state, content types, and response codes. It does not replace the application’s actual protocol and business rules. GraphQL, gRPC, WebSocket, event-driven, partner, and internal APIs need protocol-specific cases in addition to this common workflow.

Verify state and asynchronous effects

Read back the exact object after any create, update, link, approve, export, or delete attempt. Check whether a denied request still changed a field or emitted a job. Inspect the authorized monitoring view for messages, webhooks, emails, events, billing calls, and downstream requests. Where processing is asynchronous, define how long to wait and which terminal state proves the test finished.

Keep resource testing bounded

API4 and API6 do not require knocking over a service. Test just below, at, and just above an approved boundary with synthetic accounts and capped downstream integrations. Verify that controls work per identity, tenant, route, operation, and business outcome where appropriate. Confirm the service recovers and that alerts reach an owner. Stop before the test threatens availability, spending, customer inventory, or external providers.

Contain SSRF testing

Use an owner-controlled receiver that records a benign callback. Do not target cloud metadata services, internal addresses, third-party domains, or arbitrary schemes. Test URL parsing, allowlists, DNS behavior, redirects, egress policy, timeouts, and response-size limits inside the approved boundary. The goal is to prove destination control, not to reach a sensitive internal service.

Use an API finding record that engineers can replay

Field	What to record
Identity	Finding ID, API, environment, host, route or operation, version, deployment artifact, owner, and time.
Rule	OWASP category, expected policy or business invariant, source, and acceptance condition.
Fixture	Sanitized subject, role, tenant, owned object, property set, workflow state, and token condition.
Variation	The one identifier, field, method, sequence, limit, destination, or version changed.
Observation	Status, response shape, timing, side effects, saved-state read-back, logs, metrics, and request ID.
Consequence	Reachability, data or action exposed, privilege, tenant boundary, business impact, blast radius, and confidence.
Remediation	Root source, code or policy owner, change ID, review, deployment, rollback, and residual risk.
Regression	Exact allow and deny cases, automated test location, release gate, last passing version, and next review.

Prioritize by reachable consequence, not by category number or finding count. An unauthorized cross-tenant write deserves attention before a harmless documentation mismatch. A missing inventory owner can still be urgent when it leaves a deprecated privileged API exposed. Confidence matters: a repeatable state change is different from a scanner label without the necessary identity or fixture.

Fix the authoritative source and close the loop

Trace the failure to the earliest source that should enforce the rule: application authorization, identity configuration, schema, serializer, validation, workflow state machine, resource policy, gateway route, egress policy, infrastructure code, deployment template, or integration client. A gateway patch may provide immediate containment, but it should not hide a missing object-level check in the service.

NIST SP 800-228 Update 1 frames API protection across development and runtime and supports incremental, risk-based control adoption. Apply that lifecycle view: prevent unsafe design, test implementation before release, enforce runtime policy, observe operating behavior, and feed incidents and drift back into development.

1. Preserve the original failing case and sanitized evidence.
2. Write the corrected rule and expected allow and deny outcomes.
3. Change the authoritative code, policy, schema, or configuration under review.
4. Deploy through the controlled path and verify the intended artifact and environment.
5. Rerun the exact failing case, the valid control case, and nearby boundary cases.
6. Read back state and asynchronous effects, then confirm logs and alerts.
7. Promote the case into automated regression and attach it to the release gate.

Common failure modes

Running ten scanner checks and declaring coverage

A tool can find known patterns, but it does not know every identity, tenant, object owner, sensitive property, business invariant, undocumented route, or third-party trust decision. Use tools inside a test model, not instead of one.

Testing only the documented API

Specifications can be stale or incomplete. Reconcile gateway, deployment, client, and observed traffic evidence. Keep old versions in scope until they are demonstrably unreachable or formally accepted.

Using one administrator and one user

This misses horizontal ownership, tenant separation, field permissions, service identities, workflow state, and delegated administration. Build fixtures that represent the real policy dimensions.

Stopping at 401, 403, or 429

The response may disagree with saved state or downstream effects. Verify the object, queue, message, billable action, logs, and alert. Also run the legitimate control case so a fail-closed outage is not mistaken for a secure fix.

Stress testing production to prove limits

Unbounded traffic creates the harm the test is meant to prevent. Use synthetic accounts, small boundary tests, stubs, quotas, cost guards, monitoring, and stop conditions.

Closing the ticket without a regression

Authorization and inventory failures often return when routes, fields, roles, or versions change. Keep the smallest reproducing allow and deny cases in CI or another controlled release check.

Decision

The fastest useful starting point is one important API, one reconciled inventory, and a fixture set that represents its real identities, tenants, objects, fields, functions, and business states. Map that model to API1 through API10:2023, run only authorized and bounded variations, and verify response, state, side effects, and telemetry together.

The deliverable is not a clean scan badge. It is a set of replayable findings and regression cases tied to owners and release decisions. When the API changes, rerun the inventory reconciliation and the policy matrix. When OWASP, NIST, the protocol, a provider, or an integration changes, review the affected tests rather than silently assuming yesterday’s coverage still applies.

Primary references

• OWASP API Security Top 10:2023
• OWASP API Security Top 10 methodology and data
• OWASP WSTG API reconnaissance
• OWASP REST Security Cheat Sheet
• OWASP Authorization Testing Automation Cheat Sheet
• NIST SP 800-228 Update 1