API Security: The OWASP Top 10 Risks You're Probably Exposed To

APIs Are the New Perimeter

Every modern application is an API-first application. Your mobile app talks to APIs. Your frontend talks to APIs. Your microservices talk to each other via APIs. Third-party integrations? APIs.

This makes API security the single most important attack surface for most organizations. And yet, API security is consistently underprioritized compared to network security, endpoint security, or application security.

OWASP published the API Security Top 10 to address this gap. Here's a practical walkthrough.

1. Broken Object Level Authorization (BOLA)

The risk: An API endpoint returns data based on an object ID (e.g., /api/users/123/profile), but doesn't verify that the authenticated user is authorized to access that specific object. Changing 123 to 124 returns another user's data.

Why it's #1: BOLA is trivial to exploit, incredibly common, and difficult to detect with automated scanning. Every endpoint that takes an object ID is a potential BOLA vulnerability.

Defense: Check authorization for every object access. Don't rely on obscurity of IDs (UUIDs help but don't solve the problem). Implement middleware that verifies the requesting user has permission to access the specific resource.

2. Broken Authentication

The risk: Weak authentication mechanisms, missing rate limiting on login, predictable tokens, credentials in URLs, lack of token expiration, or accepting weak passwords.

Real impact: API authentication is often simpler (and weaker) than web authentication. API keys transmitted in query strings end up in server logs. JWT tokens without expiration persist forever if leaked.

Defense: Use OAuth 2.0 / OIDC for user-facing APIs. Rotate API keys. Set short JWT expiration times. Rate-limit authentication endpoints. Never put credentials in URLs.

3. Broken Object Property Level Authorization

The risk: An API returns more data than the client should see (excessive data exposure) or accepts modifications to properties the user shouldn't be able to change (mass assignment).

Example: A user profile update endpoint accepts a JSON body. If the API blindly applies all fields, an attacker can send {"role": "admin"} and escalate their privileges.

Defense: Explicitly define which fields are readable and writable for each user role. Never blindly map request bodies to database objects. Use response DTOs that exclude sensitive fields.

4. Unrestricted Resource Consumption

The risk: APIs without rate limiting, pagination limits, or resource constraints can be abused for denial of service, data harvesting, or cost inflation (especially for cloud APIs billed by usage).

Example: An endpoint that returns search results without pagination. An attacker queries with a wildcard and downloads your entire dataset. Or an AI endpoint without rate limiting that generates $50,000 in compute costs overnight.

Defense: Implement rate limiting per user/API key. Set maximum page sizes. Cap resource-intensive operations. Monitor for anomalous usage patterns.

5. Broken Function Level Authorization

The risk: Administrative or privileged API endpoints that are accessible to regular users. The admin panel might be locked down, but the underlying API endpoint /api/admin/users/delete is wide open.

Defense: Default-deny for administrative endpoints. Verify role/permission at the controller level, not just in the UI. Audit all endpoints for authorization requirements.

6. Unrestricted Access to Sensitive Business Flows

The risk: APIs that automate business processes without protecting against abuse. Automated ticket purchasing (scalping), bulk account creation, automated content scraping.

Defense: Identify business-critical flows and add protections: CAPTCHA, rate limiting, anomaly detection, step-up authentication for high-value actions.

7. Server-Side Request Forgery (SSRF)

The risk: An API accepts a URL as input and fetches it server-side. An attacker provides an internal URL (http://169.254.169.254/latest/meta-data/ for AWS metadata, http://localhost:6379 for Redis) and the server dutifully makes the request.

Impact: SSRF has contributed to major breaches. The 2019 Capital One incident involved a misconfigured WAF combined with SSRF that allowed access to AWS metadata endpoints and ultimately exposed over 100 million records.

Defense: Validate and sanitize all URLs. Block requests to internal IP ranges, cloud metadata endpoints, and localhost. Use an allowlist of permitted domains where possible.

8. Security Misconfiguration

The risk: Default credentials, unnecessary HTTP methods enabled, verbose error messages exposing stack traces, missing security headers, CORS set to *.

Defense: Harden API server configurations. Disable debug mode in production. Set restrictive CORS policies. Remove default accounts and credentials. Use security header best practices.

9. Improper Inventory Management

The risk: Organizations don't know which APIs exist. Shadow APIs, deprecated endpoints still running, test environments exposed to the internet, old API versions with known vulnerabilities.

Why this matters for vulnerability management: You can't monitor what you don't know about. An API that isn't in your inventory won't get patched when a CVE drops for its framework.

Defense: Maintain an API inventory. Decomission old versions. Use API gateways for centralized visibility. Scan for unexpected endpoints.

10. Unsafe Consumption of APIs

The risk: Your application trusts data from third-party APIs without validation. If a partner API is compromised or returns malicious data, your application processes it blindly.

Defense: Validate and sanitize all data received from external APIs. Don't assume third-party responses are safe. Implement timeouts and circuit breakers.

API Security and CVE Management

Many API vulnerabilities aren't tracked as CVEs, they're implementation bugs specific to your code. But the frameworks your APIs run on (Express, FastAPI, Spring Boot, Rails) do have CVEs, and those CVEs can enable or amplify the OWASP Top 10 risks.

A deserialization CVE in your API framework can turn a safe endpoint into an RCE vector. An authentication bypass CVE can make your entire BOLA defense irrelevant.

This is why monitoring CVEs in your API stack matters as much as writing secure code. Your code might be perfect, but if the framework underneath has a hole, the result is the same.