APIs have become the connective tissue of modern software. Every mobile app, web frontend, IoT device, and partner integration speaks to services through APIs, and the volume of API traffic now dwarfs traditional web traffic by orders of magnitude. This shift has made APIs the primary attack surface for modern applications. The OWASP API Security Top 10 catalogs the most common and dangerous API vulnerabilities, and understanding them is essential for anyone building or defending APIs.
The Shift in Attack Patterns
Traditional web application security assumed a browser client rendering HTML. APIs break that model. A machine client has no CSRF cookies to steal, no DOM to manipulate, and no rendering engine to exploit. But it does have:
- ▸Predictable endpoints that attackers can discover through documentation, reverse engineering, or scanning
- ▸Programmable clients that can scale attacks beyond what human testers ever could
- ▸Complex authorization logic that is hard to get right and easy to get wrong
- ▸Sensitive data flows where a single vulnerability can expose entire user populations
The result is that API-specific risks dominate breach reports. The OWASP API Top 10 reflects this reality by focusing on issues unique to API contexts.
Broken Object Level Authorization
The number one API risk is also the most common. An endpoint like GET /api/users/123 might correctly authenticate the caller but fail to verify that the caller is allowed to read user 123. Attackers simply change the ID and walk through every record in the system. This is known as BOLA, and it shows up in nearly every penetration test.
Defense requires checking authorization on every object access, not just at login. Authorization should be enforced in a consistent layer, ideally through policy engines rather than scattered if-statements. Automated testing with a non-admin account walking common object IDs catches many cases.
Broken Authentication
API authentication is a frequent weak point. Common failures include:
- ▸Tokens without expiration that remain valid indefinitely
- ▸Weak password recovery flows that can be abused to take over accounts
- ▸Missing rate limiting on login endpoints, enabling credential stuffing
- ▸JWT mistakes like accepting the "none" algorithm or verifying with the wrong key
- ▸Hardcoded credentials left in mobile apps or client-side code
Defense involves modern authentication standards like OAuth 2.1 and OpenID Connect, short-lived tokens, strong password policies, and aggressive rate limiting on authentication endpoints.
Excessive Data Exposure
APIs often return more data than the client needs. A user endpoint might return email, phone, address, and date of birth when the client only displays the name. Attackers inspect responses and extract the extra data for their own purposes. The fix is strict response shaping: return only what the client needs, and never rely on client code to filter sensitive fields.
Lack of Resources and Rate Limiting
Without rate limiting, APIs are trivial to abuse. Attackers can mine data, brute force credentials, or cause denial of service simply by calling endpoints in a loop. Production APIs should enforce:
- ▸Per-user rate limits that prevent abuse by authenticated clients
- ▸Per-IP limits that defend against anonymous attacks
- ▸Concurrency limits to protect downstream dependencies
- ▸Response size limits to prevent expensive queries
- ▸Request quotas for commercial API tiers
Broken Function Level Authorization
Some endpoints are sensitive even when object-level checks pass. An admin-only function should reject non-admin callers, but many APIs check the role at the frontend and trust the request once it reaches the backend. Attackers bypass the frontend and call the endpoint directly. Defense requires consistent role and permission checks at the backend for every sensitive function.
Mass Assignment
Frameworks that automatically bind request bodies to objects are convenient but dangerous. An attacker can add fields the API did not intend to accept, like an "isAdmin" flag or a "balance" override. The fix is explicit allowlisting of which fields each endpoint accepts, rather than trusting the client to send only what it should.
Security Misconfiguration
Default configurations are rarely secure. Common issues include:
- ▸Verbose error messages that leak stack traces and internal details
- ▸Enabled debug endpoints in production
- ▸Missing security headers like HSTS and content type options
- ▸Overly permissive CORS policies that allow any origin
- ▸Outdated dependencies with known vulnerabilities
Security headers, hardened configuration, and regular dependency scanning are table stakes for any production API.
Improper Inventory Management
You cannot defend APIs you do not know exist. Shadow APIs, forgotten legacy versions, and undocumented endpoints are common sources of compromise. API discovery tools help maintain a complete inventory. Every API should be documented, assigned an owner, classified by sensitivity, and regularly tested.
Unsafe Consumption of APIs
Your API probably consumes other APIs too. Treat those dependencies with skepticism. Validate their responses, enforce timeouts, limit the data you pass to them, and monitor for anomalies in the traffic they send you. A compromise of a third-party API should not automatically compromise yours.
A Defense Strategy
No single tool solves API security. Mature programs combine an API gateway for centralized enforcement, a web application and API protection solution for runtime defense, automated testing in CI, regular penetration testing, and clear ownership for every API. Do those things well, and you will be far ahead of the attackers.