Most enterprises now expose far more APIs than user interfaces. This shift has made API security one of the most consequential areas of application security. Attackers know it too, which is why API attacks have become the dominant breach vector across multiple sectors. The OWASP API Security Top 10 is the most useful checklist for engineering leaders trying to understand the threat landscape and the controls that mitigate it. This guide walks through the current list with the practical actions that prevent each risk.
Why APIs Are Different
Traditional web application security focused on rendered pages and form submissions. APIs are different in ways that change the threat model:
- ▸Higher throughput makes brute force and enumeration more dangerous
- ▸Direct data access without UI filtering exposes more
- ▸Inconsistent authentication across many endpoints creates gaps
- ▸Automation friendliness that helps developers also helps attackers
- ▸Loose documentation that lags behind actual implementation
The result is that API security cannot rely on web application security tools alone.
API1: Broken Object Level Authorization
The most common API vulnerability. Endpoints expose resources by identifier without checking whether the caller has permission for that specific resource. An attacker simply changes the ID and gains access to other users data.
Prevention requires:
- ▸Authorization checks on every endpoint that handles a resource ID
- ▸Object level authorization service centralized to avoid inconsistent checks
- ▸Unpredictable identifiers that resist enumeration
- ▸Test cases that explicitly probe authorization
- ▸Code review that verifies authorization on every handler
This vulnerability often passes functional testing because the code returns the right data for legitimate users. Adversarial testing is essential.
API2: Broken Authentication
Authentication weaknesses are still common despite years of attention. Specific patterns include weak passwords, insecure token handling, missing rate limits on login, and inadequate session management.
Prevention requires:
- ▸Standard authentication libraries rather than custom implementations
- ▸MFA support wherever sensitive operations occur
- ▸Token best practices including short lifetimes and rotation
- ▸Rate limiting and lockouts on authentication endpoints
- ▸Secure session handling with appropriate revocation
- ▸Credential storage that follows current best practices
Authentication is the front door. Treat it accordingly.
API3: Broken Object Property Level Authorization
A subtler form of the API1 problem. Even when an endpoint correctly checks access to a resource, it may expose properties the caller should not see or accept properties the caller should not modify. Mass assignment vulnerabilities sit here, as do excessive data exposure issues.
Prevention requires:
- ▸Explicit property allowlists for both reads and writes
- ▸Per role response shaping so different callers see different fields
- ▸Schema enforcement that rejects unexpected input properties
- ▸Tests that verify privileged fields remain protected
Frameworks that automatically map request bodies to objects make this problem easy to introduce. Treat such mappings with care.
API4: Unrestricted Resource Consumption
APIs allow expensive operations that consume CPU, memory, network, or database resources. Without limits, attackers can degrade service or run up bills in cloud environments.
Prevention requires:
- ▸Rate limiting per user, per IP, and per operation
- ▸Quota management for tenants and accounts
- ▸Resource limits on individual requests including timeouts
- ▸Pagination caps on list endpoints
- ▸Query complexity limits especially for GraphQL
- ▸Concurrency limits to protect downstream systems
Resource consumption attacks are often as damaging as data breaches but receive far less attention.
API5: Broken Function Level Authorization
Different API consumers should have access to different functions. Without function level authorization, lower privilege users can invoke administrative endpoints simply by knowing the URL.
Prevention requires:
- ▸Default deny for sensitive functions
- ▸Role based or attribute based access control
- ▸Function level authorization independent of object authorization
- ▸Tests that verify low privilege roles cannot call privileged functions
- ▸API gateway enforcement as a secondary control
Administrative interfaces deserve particular attention. They are highly valuable to attackers.
API6: Unrestricted Access to Sensitive Business Flows
Some attacks do not exploit a single vulnerability. They abuse business logic at scale. Account creation, password reset, refund, or commenting can each be abused if the business flow permits unrestricted execution.
Prevention requires:
- ▸Business flow modeling that identifies abuse scenarios
- ▸Behavioral controls like CAPTCHAs or proof of work where appropriate
- ▸Velocity limits on sensitive flows
- ▸Anomaly detection to flag unusual patterns
- ▸Friction tied to risk so suspicious activity faces more checks
This category often involves product and security collaboration. Pure technical controls are not enough.
API7: Server Side Request Forgery
When an API accepts a URL and fetches it, attackers can redirect that fetch toward internal services. The result is access to internal resources, cloud metadata services, or external attack pivots.
Prevention requires:
- ▸URL allowlists rather than blocklists
- ▸DNS rebinding protection
- ▸Network segmentation that limits what API hosts can reach
- ▸Metadata service protection on cloud providers
- ▸Disable redirects or carefully control them
- ▸Outbound request review for unexpected destinations
SSRF often appears in features like webhook validation or file fetching. Audit them carefully.
API8: Security Misconfiguration
A broad category covering hardening, error handling, headers, CORS, and a dozen other configuration concerns. Misconfigurations are common because there are many of them and defaults are not always secure.
Prevention requires:
- ▸Hardened baselines for every service type
- ▸Configuration as code with version control
- ▸Drift detection that flags deviations
- ▸Regular security scans including configuration checks
- ▸Patch management with documented cadence
- ▸Error handling that does not leak internals
Misconfiguration scanning catches issues that code review misses.
API9: Improper Inventory Management
Many breaches involve forgotten APIs. Old versions, debugging endpoints, deprecated services, or shadow deployments slip past security because no one tracks them.
Prevention requires:
- ▸API inventory with mandatory registration
- ▸Discovery scans that find unregistered APIs
- ▸Lifecycle management including formal deprecation
- ▸Environment separation so test endpoints do not leak to production
- ▸Documentation requirements as part of the deployment process
- ▸Periodic audits that close known gaps
You cannot secure what you do not know exists.
API10: Unsafe Consumption of APIs
APIs increasingly call other APIs. Trusting downstream responses uncritically leads to vulnerabilities including injection, data tampering, and exposed credentials.
Prevention requires:
- ▸Validation of responses from third party APIs
- ▸Timeouts and circuit breakers for downstream calls
- ▸Schema validation on inbound responses
- ▸TLS verification to prevent man in the middle
- ▸Credential hygiene with rotation and least privilege
- ▸Vendor risk assessment for critical dependencies
The trust boundary extends beyond your own services. Treat it accordingly.
Building an API Security Program
Beyond the individual risks, a working API security program needs:
- ▸API gateways that enforce common controls
- ▸Authentication and authorization standards applied consistently
- ▸API testing tools including SAST, DAST, and fuzzing
- ▸Runtime protection that detects anomalies
- ▸Developer education on secure patterns
- ▸Incident playbooks for API specific events
The OWASP API Top 10 provides the map. The program is how you actually move across the territory. Start with inventory and authorization. Add the rest incrementally. The companies that build mature API security capabilities now will avoid the breaches that will hit those who delay.