API Security: OWASP API Top 10 and Defense Strategies

APIs are the primary attack surface for modern applications. The OWASP API Security Top 10 (2023) catalogs the most critical risks facing APIs. This guide covers each risk and practical defenses.

OWASP API Security Top 10 (2023)

API1:2023 - Broken Object Level Authorization (BOLA)

This is the most common API vulnerability. It occurs when an API endpoint accepts an object identifier from the client and does not verify that the requesting user is authorized to access that object.

For example, GET /api/v1/accounts/12345 returns account data without verifying that the authenticated user owns account 12345.

To defend against BOLA, implement authorization checks on every request that accesses a resource by ID. Use the authenticated user’s session or token to derive which objects they can access rather than relying on client-supplied ownership claims. Prefer UUIDs over sequential integers to reduce enumeration risk, though this is not a substitute for authorization. Write automated tests that verify user A cannot access user B’s resources.

API2:2023 - Broken Authentication

Weak or missing authentication mechanisms allow attackers to assume other users’ identities.

Common issues include accepting weak passwords or not enforcing MFA, exposing credentials in URLs or logs, not validating JWT signatures or expiration, and missing brute-force protection on login endpoints.

Use established authentication frameworks (OAuth 2.0, OpenID Connect) rather than custom implementations. Validate all JWT claims including signature, expiration (exp), issuer (iss), and audience (aud). Implement account lockout or progressive delays after failed attempts. Never expose tokens in URLs; use Authorization headers and HttpOnly cookies. Rotate secrets and signing keys on a defined schedule.

API3:2023 - Broken Object Property Level Authorization

APIs that expose more object properties than necessary or allow clients to modify properties they should not.

For example, a PATCH /api/v1/users/me endpoint allows setting {"role": "admin"} because the API blindly accepts all properties.

Define explicit allowlists for readable and writable properties per endpoint and role. Never bind request payloads directly to internal data models (mass assignment). Return only the fields the client needs rather than generic SELECT * responses. Review API documentation and schemas to ensure sensitive fields are excluded.

API4:2023 - Unrestricted Resource Consumption

APIs that do not limit how many resources a single client can consume enable denial-of-service and cost-based attacks.

Implement rate limiting per client and per endpoint using token bucket or sliding window algorithms. Set maximum request payload sizes. Limit pagination by enforcing maximum page_size values and total result caps. Set timeouts on backend operations including database queries and external API calls. Use API gateways (Kong, AWS API Gateway, Apigee) to enforce quotas centrally. Monitor for anomalous consumption patterns.

API5:2023 - Broken Function Level Authorization

Users can access administrative or privileged API endpoints by simply changing the URL path or HTTP method.

For example, a regular user calls DELETE /api/v1/admin/users/456 and it succeeds.

Deny access by default and explicitly grant permissions per role per endpoint. Centralize authorization logic in middleware rather than scattering checks across handlers. Separate administrative endpoints into distinct API modules or paths with additional authentication requirements. Test authorization for every endpoint with unprivileged credentials.

API6:2023 - Unrestricted Access to Sensitive Business Flows

Automated abuse of legitimate business flows includes bulk account creation, ticket scalping, and coupon abuse.

Implement CAPTCHA or proof-of-work challenges for sensitive flows. Use device fingerprinting and behavioral analysis. Apply rate limiting specifically tuned to business flow thresholds. Require step-up authentication for high-value operations.

API7:2023 - Server Side Request Forgery (SSRF)

APIs that fetch external resources based on user-supplied URLs can be tricked into accessing internal services.

Validate and sanitize all user-supplied URLs. Maintain an allowlist of permitted external domains. Block requests to private IP ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x, localhost). Use a dedicated outbound proxy with network-level restrictions. Disable unnecessary URL schemes (file://, gopher://, dict://).

API8:2023 - Security Misconfiguration

Insecure default configurations, unnecessary HTTP methods, permissive CORS policies, and verbose error messages all contribute to this category.

Disable unnecessary HTTP methods (TRACE, OPTIONS where not needed). Configure restrictive CORS policies and never use Access-Control-Allow-Origin: * for authenticated endpoints. Return generic error messages to clients while logging detailed errors server-side. Remove default credentials, sample endpoints, and debug modes before deployment. Automate configuration validation in CI/CD pipelines. Apply security headers: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options.

API9:2023 - Improper Inventory Management

Organizations lose track of API versions, endpoints, and environments, leaving deprecated or shadow APIs exposed.

Maintain a complete API inventory with ownership, version, and environment metadata. Use API gateways as a single point of entry to enforce inventory control. Decommission deprecated API versions rather than leaving them running alongside current versions. Scan for undocumented endpoints using API discovery tools. Require all APIs to be registered in a central catalog before deployment.

API10:2023 - Unsafe Consumption of Third-Party APIs

Blindly trusting data from third-party APIs without validation creates risk.

Validate and sanitize all data received from external APIs. Enforce timeouts and circuit breakers on third-party calls. Use TLS for all external API communication and verify certificates. Apply the principle of least privilege to third-party API credentials. Monitor third-party API responses for unexpected changes in schema or behavior.

Cross-Cutting API Security Controls

Authentication and Authorization Architecture

For most applications, use OAuth 2.0 with short-lived access tokens and refresh tokens. Access tokens should have 5-15 minute expiration. Refresh tokens can last hours to days, with rotation on each use. Define granular scopes per API resource. For token storage, use server-side sessions or HttpOnly/Secure cookies, never localStorage.

Input Validation

Validate all inputs against a strict schema (JSON Schema, OpenAPI spec, or framework-level validation). Reject unexpected fields rather than ignoring them. Enforce type, length, format, and range constraints. Sanitize inputs used in database queries, OS commands, or downstream API calls.

Logging and Monitoring

Log every API request with timestamp, client IP, and user identity. Include the endpoint, HTTP method, and response status code. Record request duration and payload size but not sensitive content.

Set up alerts for authentication failure spikes, authorization denial patterns, rate limit breaches, unexpected 5xx error rates, and new or undocumented endpoints receiving traffic.

API Gateway Best Practices

An API gateway provides centralized enforcement of authentication (JWT validation, API key verification), rate limiting and throttling, request/response transformation and validation, TLS termination, and logging and metrics collection.

Security Testing

Use SAST to scan API source code for injection vulnerabilities and insecure patterns. Run DAST with automated API security scanners (Burp Suite, OWASP ZAP, Nuclei) against deployed APIs. Conduct manual testing for authorization boundary testing, verifying every endpoint with every role. Use contract testing to validate that API responses match OpenAPI specifications. Run dependency scanning to check third-party libraries used by the API for known vulnerabilities.