OWASP API Security Top 10: What Changed and How to Protect Your APIs

BOLA (formerly IDOR—Insecure Direct Object Reference) has topped the OWASP API list since 2019 and remains the most exploited API vulnerability. It occurs when an API endpoint accepts an object ID in a request but fails to verify that the authenticated user is authorized to access that specific object. An attacker simply increments or guesses object IDs to access other users' data.

Remediation: Implement object-level authorization checks on every endpoint. Never trust client-supplied IDs—always validate ownership server-side. Use indirect references (UUIDs, tokens) instead of sequential integers.

Authentication mechanisms in APIs are frequently misconfigured or implemented incorrectly. Common failures include: JWT tokens that are not verified server-side, weak or missing token expiry, credential stuffing with no rate limiting, API keys transmitted in URLs (logged in access logs), and password reset flows that bypass authentication entirely.

Remediation: Use industry-standard authentication libraries. Enforce token expiry and rotation. Implement rate limiting and account lockout. Never include credentials in URLs. Use short-lived JWTs with refresh token rotation.

New in 2023, this consolidates "Excessive Data Exposure" and "Mass Assignment" from the 2019 list. The vulnerability exists when an API allows users to read or write object properties they should not have access to. Mass assignment attacks occur when an API blindly binds all request body fields to internal objects, allowing attackers to set privileged fields like is_admin: true.

Remediation: Use explicit allow-lists for both request and response fields. Never pass raw request objects directly to your ORM. Return only the properties each user role is entitled to see.

Replaces "Lack of Resources and Rate Limiting" with a broader scope. This covers scenarios where APIs have no limits on request size, query complexity (GraphQL depth attacks), file upload sizes, third-party API call costs per user action, or execution timeouts. Resource exhaustion attacks can render services unavailable or generate massive unexpected cloud costs.

Remediation: Implement rate limiting per user, per IP, and per endpoint. Cap request body sizes. Set GraphQL query depth and complexity limits. Implement timeouts for all downstream calls. Monitor and alert on unusual usage spikes.

Different from BOLA (object-level), this vulnerability exists at the endpoint/function level. Admin-only endpoints are often accessible to regular users when authorization is not enforced on the server. Attackers probe for predictable admin endpoint patterns (/admin/, /internal/, HTTP method switching) and find that client-side UI hiding is the only "protection."

Remediation: Enforce role-based access control (RBAC) on every API endpoint at the middleware layer, not just in the UI. Audit admin functionality regularly. Use allowlist-based authorization rather than denylists.

New in 2023. This addresses automation abuse of legitimate business workflows—scraping inventory to corner a market, buying all limited-edition items, bulk coupon abuse, mass fake account creation, and credential stuffing at scale. The API is technically functioning correctly; the problem is that automated abuse is indistinguishable from legitimate usage.

Remediation: Implement bot detection and device fingerprinting. Add CAPTCHA to high-risk flows. Enforce purchase/signup velocity limits. Monitor for unusual behavioral patterns. Consider friction (email verification, phone verification) for sensitive flows.

SSRF vulnerabilities allow attackers to make the API server issue requests to internal services or metadata endpoints on their behalf. In cloud environments, a successful SSRF against the AWS metadata service at 169.254.169.254 can expose IAM credentials with production access. SSRF is especially dangerous when APIs accept user-controlled URLs for webhooks, image fetching, or link previews.

Remediation: Validate and sanitize all user-supplied URLs. Maintain an allowlist of permitted destinations. Block requests to private IP ranges and cloud metadata endpoints. Use IMDSv2 on AWS to require session tokens for metadata access.

The broadest category. Includes: permissive CORS policies (accepting * origins), verbose error messages exposing stack traces or database schemas, unnecessary HTTP methods enabled, missing security headers (HSTS, CSP, X-Content-Type), default credentials on API management gateways, and TLS misconfiguration.

Remediation: Use automated security header scanners in CI. Enforce strict CORS policies. Disable HTTP methods not in use. Return generic error messages to clients. Scan API gateways and proxies as part of your infrastructure security review.

Organizations often cannot enumerate all the APIs they expose. Shadow APIs (endpoints not in any documentation), zombie APIs (deprecated versions left running), and third-party integrations create attack surface that security teams cannot monitor. Attackers probe for v1, v2, beta, and internal API versions that often lack the security controls applied to the latest production API.

Remediation: Maintain an up-to-date API inventory with OpenAPI specifications. Decommission deprecated API versions. Use API gateways to enforce routing through known endpoints. Run discovery scans to find undocumented APIs in production.

New in 2023. This reflects the supply chain risk of the APIs your application consumes. When developers blindly trust third-party API responses—passing them to SQL queries, deserializing without validation, redirecting users based on returned URLs—a compromise of the third-party API becomes a compromise of your application. This vulnerability class became prominent after several high-profile supply chain attacks involving compromised API providers.

Remediation: Validate and sanitize all data received from external APIs. Treat third-party API responses as untrusted input. Implement circuit breakers for external dependencies. Monitor third-party API response patterns for anomalies.