API Security 2026: The Complete OWASP API Top 10 + Testing Methodology Guide

#The API security conversation every CTO hates

"Do you test your APIs?"

"Of course. We have a SAST tool."

"Does it test authorization? Broken object-level authorization? Broken function-level authorization? Rate limiting? Mass assignment? Unrestricted resource consumption?"

"It covers... some of that. Through our pentest."

"When was the last pentest that specifically scoped APIs, not just the web app frontend?"

"... I'll have to check."

This is 90% of the API security conversations I have with engineering leadership. The APIs are the highest-value part of most businesses' attack surface in 2026 and also the part that most frequently gets tested incorrectly or not at all. OWASP's API Security Top 10 covers the specific failure patterns, and almost every issue on the list is a business logic bug that no scanner catches and no generic web application tester thinks to look for.

This post is the complete API security guide. Every OWASP API Top 10 category explained with real attack patterns. The specific controls that address each. Authentication architectures. API gateway tradeoffs. Rate limiting patterns that actually work. Testing methodology. And the 2026 landscape where every SaaS, every mobile app, and every microservices architecture is now API-first.

#Who this is for

• Engineering leaders at API-first SaaS companies.
• Security engineers tasked with scoping API testing.
• Backend developers writing APIs.
• Platform engineers running API gateways.
• Third-party integrators consuming APIs at scale.

#What changed between APIs and traditional web apps

Classical web application security was built around the browser. The browser enforces same-origin policy, attaches cookies automatically, runs JavaScript in a sandbox, and renders HTML. Traditional security tools understood this model.

APIs are different. No browser. No cookie attachment (usually). No HTML rendering. The client is whatever sends requests. Mobile apps. JavaScript SPAs. Native applications. Server-to-server integrations. Third-party consumers.

What changes as a result:

• Authentication via tokens, not sessions
• Authorization decisions on every request
• No HTML injection class of attacks
• Massive exposure to business logic bugs
• Rate limiting is on the server, not assumed from user click-rate
• Logging and auditing become central to visibility

#The OWASP API Security Top 10 (2023)

The most recent version of the OWASP API Top 10. Worth memorizing because every API security engagement touches most of them.

#API1. Broken Object Level Authorization (BOLA)

The single most common and highest-impact API vulnerability. Still. Year after year.

The pattern. User authenticates. Endpoint is GET /api/invoices/{id}. Application checks that the user is authenticated (yes, signed in) but not that the user owns invoice {id}. User #1 requests GET /api/invoices/42. Gets user #2's invoice.

The variations:

• Integer incrementing IDs exposed
• UUIDs exposed but predictable or leakable
• Indirect references that fail authorization (/api/teams/{teamId}/projects/{projectId} where project authorization isn't checked)
• IDOR in update operations (PUT /api/users/{id} where any authenticated user can update any user)
• IDOR in delete operations (particularly nasty)

Defense:

• Authorization check on every object access
• Object-level authorization decorators or middleware
• Shift-left: write authorization tests alongside functional tests
• Never trust the ID from the request. Look up ownership server-side.

#API2. Broken Authentication

Authentication implementation failures. JWT handling bugs, session token issues, authentication bypass patterns.

Common patterns:

• JWT accepting "none" algorithm
• JWT verification with the wrong key
• Predictable session tokens
• Password reset flows that don't invalidate sessions
• Missing MFA on sensitive operations
• Account enumeration via different error messages
• Username/password brute force with no rate limiting

Defense:

• Use well-maintained auth libraries. Don't roll your own JWT handling.
• Explicit algorithm whitelist on JWT verification
• Short-lived access tokens + refresh tokens with rotation
• MFA for sensitive operations beyond login
• Generic error messages for authentication failures
• Rate limiting on authentication endpoints

#API3. Broken Object Property Level Authorization

Subset of BOLA focused on individual properties. User is authorized to access the object but not all properties of it.

Examples:

• Admin panel returns user objects with internal notes, password hashes, or PII fields to lower-privileged users
• Mass assignment vulnerabilities where a PUT request lets an attacker set fields they shouldn't be able to set (role, status, etc.)
• Response includes sensitive data the client UI hides but attacker can see in network tab

Defense:

• Explicit response DTOs (data transfer objects) with only allowed fields
• Explicit request DTOs excluding sensitive fields from input
• Avoid serializing entire database models to clients
• Reject extra properties in request payloads (schema validation)

#API4. Unrestricted Resource Consumption

Attacker causes the API to consume excessive resources. Denial of service, financial drain (cloud bills), or availability degradation.

Examples:

• Endpoint with pagination where attacker requests page_size=1000000
• Expensive queries triggered by attacker
• File upload with no size limit
• Recursive data structures
• Regex DoS (ReDoS)
• Unrestricted email sending (costs + rate limits + reputation)

Defense:

• Request rate limiting
• Request size limiting
• Pagination limits with reasonable defaults
• Query complexity analysis (especially for GraphQL)
• Resource quotas per user
• Timeouts on long-running operations

#API5. Broken Function Level Authorization

Authentication works. Authorization at the endpoint level doesn't. User shouldn't be able to call admin endpoints but can.

Common patterns:

• Admin endpoints relying on "admin UI doesn't link here" for protection
• Role-based authorization inconsistently applied across endpoints
• Authorization middleware not covering every route
• Method-level authorization missing (GET allowed for all, POST/DELETE should be admin but aren't)

Defense:

• Default-deny authorization
• Authorization as a first-class concept in the routing layer
• Automated tests that verify each role can only access authorized endpoints
• Penetration testing that explicitly tests privilege escalation across endpoints

#API6. Unrestricted Access to Sensitive Business Flows

Attacker abuses legitimate functionality in harmful ways. Not a technical bug. A business logic abuse.

Examples:

• Bulk purchase of limited-quantity items by bots (sneaker bot pattern)
• Account enumeration via sign-up flow
• Coupon code brute forcing
• Appointment booking flooding
• Gift card balance checking at scale
• Rate-limited API but unlimited via new accounts

Defense:

• CAPTCHA on high-risk operations
• Device fingerprinting to detect bot patterns
• Business logic rate limits (not just request rate)
• Behavioral anomaly detection
• Customer identification on sensitive flows

#API7. Server Side Request Forgery (SSRF)

API makes outbound requests based on client input. Client controls destination. Attacker uses the API as a proxy to reach internal services.

Examples:

• Webhook URL fields accepting internal IPs (169.254.169.254 AWS metadata)
• URL preview features fetching attacker-supplied URLs
• File download endpoints accepting arbitrary URLs
• Image processing services fetching images from user URLs

Defense:

• Allowlist outbound destinations where possible
• Block private IP ranges explicitly (RFC 1918, 169.254, localhost, 0.0.0.0)
• Use IMDSv2 (AWS) to prevent simple SSRF leading to cloud credential theft
• Validate URLs before making requests (DNS rebinding defenses)
• Network-level egress filtering where API service lives

#API8. Security Misconfiguration

Classic. Defaults not hardened, verbose errors, missing security headers, open cloud storage.

Examples:

• Stack traces in production error responses
• Debug endpoints exposed in production (actuator, Swagger with admin functions, metrics endpoints)
• Overly permissive CORS (Access-Control-Allow-Origin: * with credentials)
• Missing security headers
• Cloud storage buckets backing APIs with public access
• Default credentials on API gateway admin interfaces

Defense:

• Security configuration review as part of deployment
• Disable debug features in production
• Explicit CORS policy with specific origins
• Security headers via API gateway or middleware
• Cloud configuration monitoring

#API9. Improper Inventory Management

You don't know what APIs you have. Old API versions still live. Undocumented endpoints in production.

Examples:

• v1 of the API deprecated but still accessible
• Staging/dev APIs publicly accessible with production data
• Shadow APIs (teams built endpoints outside the API gateway)
• Third-party integrations with API keys nobody remembers
• Internal APIs exposed accidentally via misconfigured load balancer

Defense:

• API inventory (automated where possible)
• API gateway as single ingress
• Version deprecation policy and enforcement
• Regular scan for shadow APIs
• Third-party API access audit

#API10. Unsafe Consumption of APIs

Your API calls other APIs. Those other APIs get compromised or return malicious data. You trust the response.

Examples:

• Consuming a payment processor's webhook without signature verification
• Fetching user avatar from user-supplied URL without validation
• Third-party API returns malicious content that flows to your clients
• Aggregating data from upstream APIs without sanitization

Defense:

• Webhook signature verification (see our webhook forgery post)
• Content validation on third-party responses
• Sandbox untrusted content before passing to clients
• Allowlist trusted upstream API endpoints

#The API authentication pattern shootout

#Session cookies with SameSite

For APIs consumed by your own web application, this works. Set-Cookie with SameSite=Lax or Strict, HttpOnly, Secure. CSRF token for state-changing operations.

Pros: Simple. Works with browser security model.

Cons: Not suitable for mobile apps, server-to-server, third-party integrations.

#JWT with short-lived access + refresh

Access token lives 10-60 minutes. Refresh token lives days-weeks. Access token sent with every request (Authorization header). Refresh token used only to get new access tokens.

Pros: Stateless server, scales well, works across platforms.

Cons: Revocation is hard (short lifetimes help), implementation bugs are common.

#OAuth 2.0 / OpenID Connect

Standard for third-party authentication. Multiple grant types. Complex to implement correctly.

Pros: Industry standard, well-supported, allows delegated authorization.

Cons: Complexity means many implementations are wrong.

#API keys (static)

Long-lived keys, per-client, scoped to permissions.

Pros: Simple for server-to-server integrations.

Cons: Rotation is manual. Compromise is catastrophic. Not suitable for user-facing clients.

#mTLS (mutual TLS)

Both client and server present certificates. Strong authentication.

Pros: Very strong. Hard to steal credentials that never traverse the network unencrypted.

Cons: Certificate management burden. Not practical for consumer-facing APIs.

#Workload identity (cloud-native)

Service identity via cloud provider. No static credentials at all.

Pros: No credentials to steal. Automatic rotation.

Cons: Cloud-specific. Works for intra-cloud service-to-service, not external consumers.

#The API gateway layer

Most mature APIs run through a gateway. Kong, AWS API Gateway, Azure API Management, Google Apigee, Cloudflare API Gateway, Tyk.

Functions:

• Request routing
• Authentication verification (offload from application)
• Rate limiting
• Request/response transformation
• Logging and metrics
• Caching
• API key management
• Documentation (OpenAPI / Swagger)

Pros of gateway:

• Centralized policy
• Consistent authentication and rate limiting
• Centralized audit log
• Easy to add/remove endpoints

Cons of gateway:

• Additional infrastructure
• Potential single point of failure
• Can become over-engineered for simple APIs
• Vendor lock-in in some cases

For anything beyond a small internal API, a gateway is essentially mandatory.

#Rate limiting that actually works

Simple rate limiting (requests per minute per IP) is trivial to defeat and creates false positives.

Better patterns:

Token bucket per API key. Each key gets a refill rate and bucket size. Requests deplete the bucket. Unused capacity accumulates up to the bucket max.

Sliding window counters. More accurate than fixed windows. Better DDoS behavior.

Tiered limits. Different limits for different endpoints based on cost. POST /search (expensive) has tighter limits than GET /user/me (cheap).

Business rule limits. Beyond request rate. "User can create at most 10 accounts per day." "Each IP can attempt password reset at most 3 times per hour." Business logic protections.

Dynamic adjustment. Limits tighten under load or attack. Anomaly detection triggers temporary reduction.

Infrastructure:

• Kong + kong-rate-limiting plugin
• AWS WAF + Lambda custom rules
• Cloudflare Rate Limiting
• Redis-based custom implementations
• Envoy-based service mesh rate limits

#Testing methodology

How to test an API.

#Step 1. Inventory

List every endpoint. OpenAPI spec if it exists. Network capture if not. Decompile the client if the API has no docs.

#Step 2. Authentication matrix

For each endpoint, determine:

• Unauthenticated access allowed?
• Which roles are expected to have access?
• Which roles are expected to be denied?

Test each combination.

#Step 3. Object authorization

For endpoints that take object IDs, create two accounts. From account A, try to access account B's objects. Document findings.

#Step 4. Property authorization

Examine response payloads for fields the user shouldn't be able to see. Examine request bodies for fields the user shouldn't be able to set.

#Step 5. Resource consumption

Submit pagination requests with large page sizes. Submit large payloads. Trigger expensive operations rapidly.

#Step 6. Business logic

Think like an attacker. What could someone abuse? What rate limits exist? What workflows have race conditions?

#Step 7. Injection classes

SQL injection, NoSQL injection, OS command injection, LDAP injection (wherever user input reaches these).

#Step 8. Misconfiguration

CORS. Security headers. Error verbosity. Debug endpoints. Swagger UI accessibility.

#Tools

#Burp Suite Professional

The standard. Proxy traffic, manually test, scan where helpful, replay requests.

#OWASP ZAP

Free alternative to Burp. Less polished but capable.

#Postman with automated tests

Useful for functional + some security testing.

#Custom tooling

Python with requests, GraphQL-specific tools (GraphCrawler, InQL), JWT tools (jwt_tool).

#API-specific security scanners

• 42Crunch (commercial, OpenAPI-focused)
• Salt Security (runtime API security)
• Noname Security (API posture)
• Traceable AI (runtime API security)
• Akto (open source + commercial)
• StackHawk (developer-focused)

These are necessary but not sufficient. A human tester looking at business logic finds things scanners miss.

#The 2026 emerging concerns

#GraphQL security

GraphQL shifts many security concerns from the URL structure to the query structure. Specific concerns:

• Deep nesting leading to resource exhaustion
• Batched queries defeating rate limiting
• Introspection leaking schema in production
• Mutation authorization at field level

#gRPC security

gRPC increasingly common for internal APIs. Concerns:

• TLS configuration (mTLS is standard)
• Authentication via metadata
• Authorization at method level
• Streaming RPC resource limits

#Event-driven APIs

Kafka, AMQP, WebSockets, Server-Sent Events. Concerns:

• Authentication for persistent connections
• Authorization per message
• Rate limiting on connection count + message rate

#AI-integrated APIs

APIs consuming or producing LLM responses. Concerns:

• Prompt injection in input
• Sensitive data in training
• Cost control (LLMs are expensive per request)
• Output filtering

#Zero trust for APIs

Every service-to-service call authenticated. No implicit trust in the network. Workload identity, mTLS, token-based auth.

#Working with us

We run API security engagements as a primary service. Our approach:

• API inventory validation
• Systematic OWASP API Top 10 testing
• Business logic exploitation
• Authorization matrix testing
• Gateway configuration review

Valtik Studios, valtikstudios.com.