API Security Testing: OWASP API Top 10 in Practice 2026

APIs now carry more commercially-important attack surface than the UIs they power. In a modern SaaS product, the web or mobile client is a rendering layer; the actual business logic, authorization, and data access live behind an API. A good API security test finds the vulnerabilities that a web-app test pitched at the frontend would miss. A bad one — and most are bad — runs Postman against a Swagger file and calls it done.

This is the practitioner’s guide to API security testing in 2026, mapped to the OWASP API Security Top 10 (2023 edition, revised 2025) with notes on what the methodology actually looks like, what tools matter, and which findings we see most often in Indian SaaS engagements.

The OWASP API Top 10 in 2026 practice

The official list is the starting point. Each item below includes the finding-class, the real-world manifestation, and what a credible test looks like.

API1:2023 — Broken Object Level Authorization (BOLA)

The single highest-impact API finding in commercial practice. An authenticated user can access objects they should not — typically by iterating numeric IDs, substituting another user’s ID in a request path, or manipulating an identifier in the request body. The canonical example: GET /api/orders/12345 where any authenticated user can change 12345 to any valid order ID and read it.

Testing methodology: for every object identifier in the API, verify that changing it to an identifier owned by a different user (or tenant) returns 403/404, not 200. Test on GET, POST, PATCH, PUT, DELETE — authorization frequently differs across verbs. Test indirect object references too: a file download URL with a signed token that turns out to be predictable; a shareable-link identifier that is actually just an incrementing ID.

High-signal evidence for the report: a request from user A retrieving user B’s data, side-by-side with the same request from user A retrieving their own data. Business impact: customer data disclosure at scale.

API2:2023 — Broken Authentication

Covers all authentication-layer weaknesses: weak password policies, broken token validation, lack of rate limiting on credential endpoints, weak session management.

Specific tests: JWT algorithm-confusion (HS256 vs RS256 swap, “none” algorithm), token replay after logout, refresh-token handling (reuse, family invalidation), OAuth state parameter absence, PKCE enforcement for public clients, password-spray resistance across large username lists (not just the common accounts).

An under-tested area: the “forgot password” flow. Token entropy, token leakage via Referer headers, same-token reuse across reset attempts, token validity window. Also: account-lockout bypasses via X-Forwarded-For header rotation or distributed IP.

API3:2023 — Broken Object Property Level Authorization

The property-level version of BOLA, covering two sub-cases: excessive data exposure (the API returns more fields than the client should see) and mass assignment (the API accepts updates to fields the client should not be able to write).

Excessive exposure: GET /api/users/self returns the current user’s own profile including internal_flag, stripe_customer_id, admin_notes that no frontend displays. The backend is returning the full row; the frontend is filtering. An API client sees everything.

Mass assignment: PATCH /api/users/self with body {"role": "admin", "verified": true} — some backends apply all fields from the request body; the API becomes a privilege-escalation vector. Ruby on Rails applications in particular have a history of this; modern frameworks with explicit field allowlisting are safer but still break when allowlists are out of date relative to new fields.

API4:2023 — Unrestricted Resource Consumption

Missing rate limits, missing pagination limits, missing file-size limits, missing time-out enforcement. Leads to denial of service, cost amplification (for pay-per-use backends), and downstream abuse.

Practical tests: how many requests per second can a single account sustain; how large a JSON payload does the API accept; how long a regex or search query does it process; how many items can a single response return (pagination bypass via large limit parameters); how many simultaneous WebSocket connections.

Emerging in 2026: LLM-backed APIs where a single request can trigger expensive downstream model calls. A $100 request is now possible if the API exposes model-backed endpoints without prompt-length, response-length, and concurrency limits. Ask every AI-integrated endpoint: what is the maximum $ cost of a single malicious request?

API5:2023 — Broken Function Level Authorization

Not every endpoint is exposed in the frontend; authorization is enforced by URL obscurity rather than real checks. A low-privilege user calls /api/admin/users and it succeeds because no one expected a non-admin to find the URL.

Testing methodology: enumerate routes from every available source (JS bundles, Swagger/OpenAPI specs, mobile app decompilation, sitemap, historical archives). Attempt every admin-capable endpoint from a low-privilege account. Look for HTTP method transitions — maybe GET is authorized but PATCH is not, or vice versa.

The highest-signal version is the GraphQL equivalent: every resolver authorizes independently. A sensitive admin-only resolver reachable through a nested query from a user-facing resolver is still reachable. GraphQL authorization testing requires per-resolver analysis.

API6:2023 — Unrestricted Access to Sensitive Business Flows

New in the 2023 version, capturing the business-logic attacks that do not fit traditional taxonomies. Bulk-account creation to exploit referral bonuses. Automated ticket purchasing to resell. Scraping at scale. Voucher-code enumeration.

Testing requires understanding the business model. Where is value created? Where would an attacker with automation extract it? Is there friction preventing that? Common weaknesses: missing CAPTCHAs on signup when signups carry economic value; missing purchase-intent validation on limited-availability items; missing per-account velocity limits on discount code application.

API7:2023 — Server-Side Request Forgery (SSRF)

APIs that fetch remote resources on user input — webhook testers, image-preview fetchers, PDF generators loading remote CSS, OAuth discovery endpoints, LLM-integrated tools that can make HTTP requests. Attacker supplies a URL; the server fetches it; the response is reflected back or used in subsequent logic.

Canonical payload: AWS IMDS at http://169.254.169.254/latest/meta-data/iam/security-credentials/. If the API fetches and reflects response content, attacker retrieves cloud credentials. GCP and Azure have equivalents at metadata.google.internal and 169.254.169.254.

Mitigations: IMDSv2 enforced on AWS EC2; SSRF-safe URL fetchers that enforce allowlists, resolve DNS in the library not the kernel, block private IP ranges after resolution; response content type filtering.

API8:2023 — Security Misconfiguration

Catch-all for infrastructure and configuration issues: outdated components, default credentials, unnecessary features enabled, verbose error messages leaking internal state, missing security headers on API responses, permissive CORS.

Recurring in 2026 engagements: CORS configurations that reflect any origin with Access-Control-Allow-Credentials: true — this makes every API endpoint reachable by any attacker-controlled site with the victim’s session cookies. A devastating finding and surprisingly common.

API9:2023 — Improper Inventory Management

Shadow APIs, deprecated versions still running, undocumented endpoints. The v1 API was replaced by v2 two years ago, but v1 is still live, still accepts authentication, and still has all the vulnerabilities from two years ago because it has not been patched.

Testing methodology: version enumeration (try /api/v1/ through /api/v5/ even when documentation shows only current); staging/dev subdomains on production DNS; archive.org for historical API documentation; third-party docs that may name internal endpoints.

API10:2023 — Unsafe Consumption of APIs

Your API calls a third-party API and trusts the response. The third-party API is compromised; the attacker injects content into the response; your application processes it without validation.

Testing: if the API integrates with webhooks, OAuth providers, payment gateways, or external data sources, test what happens when the upstream returns malicious content. Out-of-spec JSON, oversized responses, malformed redirects, content injected into fields assumed to be safe.

Beyond the Top 10 — what we test anyway

GraphQL-specific concerns

Introspection enabled in production. Deeply nested query attacks leading to resource exhaustion. Batched query attacks bypassing per-request rate limits. Alias-based attacks duplicating sensitive fields. Inappropriate use of field-level caching. Missing authorization on union types or interface resolvers.

WebSocket authentication and authorization

Authentication at connection time but no per-message authorization. Message-level injection attacks. Cross-origin WebSocket hijacking.

gRPC and Protocol Buffers

Not exempt from the OWASP Top 10 — BOLA, mass assignment, and authorization failures manifest in gRPC exactly as in REST. Testing requires gRPC-capable tools (grpcurl, grpc-web tooling, Wireshark with protobuf plugins).

Event-driven and async APIs

Message bus authorization. Webhook signature validation. Idempotency key handling. Replay attacks on async message processing.

LLM-integrated APIs

Prompt injection testing — both direct (via user input to the API) and indirect (via content the API retrieves from documents, URLs, or databases). Tool-use attack surface (if the LLM can invoke functions, each function is an API surface needing its own authorization). Cost amplification via oversized prompts or repeated tool invocations.

Tooling for API testing in 2026

Burp Suite Professional — still dominant for interactive testing. Extensions: Autorize (authorization testing), JSON Web Tokens (JWT manipulation), GraphQL Raider.
Caido — gaining ground as a Burp alternative, particularly for team workflows.
Postman — collection-driven testing, useful for workflow reproduction; not a penetration testing tool but a common way to systematically explore an API.
mitmproxy — scriptable proxy for mobile and automation-heavy tests.
ffuf — API endpoint fuzzing and parameter discovery.
Nuclei with API templates — for known-vulnerability checks and misconfiguration scanning.
gRPCurl — for gRPC testing.
InQL — GraphQL introspection and testing.
Autorize, Authz, Authmatrix — authorization-testing automation.

The findings we see most often in Indian SaaS

Across the engagements we run, five API findings appear in roughly 70% of cases:

BOLA on a tenant or organization-scoped resource. Multi-tenant SaaS products routinely have endpoints that check user authentication but fail to check tenant membership on the specific object. Devastating when the resource is customer-sensitive.
Excessive data exposure in user or account endpoints. Full row returns with fields the frontend never displays. Internal flags, admin notes, third-party IDs.
Missing rate limits on authentication or business-critical endpoints. Signup, password reset, coupon application, referral submission.
Shadow or outdated API versions still reachable. Typically a v1 API left running after v2 migration, with known vulnerabilities never patched.
CORS misconfiguration reflecting origins with credentials. Single-line configuration bug with session-theft consequences.

None of these are exotic. All five are directly preventable with basic authorization hygiene and infrastructure review. The reason they persist is that API security is often treated as an afterthought relative to frontend-facing security testing — a gap that changes in cost once the first enforcement-relevant breach happens.

API Security Testing: OWASP API Top 10 in Practice (2026)