API Security
OWASP API Security Top 10 Explained
The OWASP API Security Top 10 (2023) lists: API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server-Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management, API10 Unsafe Consumption of Third-Party APIs.
Andreas Johansson · Chief Executive Officer
Senior IT management leader with 25 years of experience in Cloud, Security, and Datacenter infrastructure.
What Is the OWASP API Security Top 10?
The OWASP (Open Worldwide Application Security Project) API Security Top 10 is a consensus-driven list of the most critical API security risks. It provides a standardized framework for understanding, testing, and mitigating API vulnerabilities.
The list was updated in 2023 to reflect evolving API threats. It serves as a baseline for API security programs, penetration testing scope, and developer security training.
API2:2023 — Broken Authentication
- Risk: Flawed authentication mechanisms that allow attackers to assume other users' identities.
- How it works: Weak token generation, missing authentication on endpoints, tokens that don't expire, credentials in URLs, no brute-force protection.
- Prevention:
- Use industry-standard auth (OAuth 2.0, OpenID Connect)
- Short-lived tokens with secure refresh flows
- Rate limit authentication endpoints
- Never expose credentials in URLs or logs
API4:2023 — Unrestricted Resource Consumption
- Risk: APIs without limits on resource consumption — request rates, payload sizes, response counts.
- How it works: Attackers send excessive requests (DoS), upload oversized files, request massive data sets, or trigger expensive operations repeatedly.
- Prevention:
- Rate limiting per user, key, and IP
- Payload size limits
- Pagination with maximum page sizes
- Timeout limits on expensive operations
- Resource quotas per account
API6:2023 — Unrestricted Access to Sensitive Business Flows
- Risk: APIs that expose business flows (purchasing, booking, commenting) without protections against automated abuse.
- How it works: Bots automate business processes — buying limited inventory, creating fake accounts, scraping content, submitting spam. The API works as designed, but at a scale and speed that's abusive.
- Prevention:
- Bot detection and CAPTCHA for sensitive flows
- Business logic rate limiting (not just request rate limiting)
- Device fingerprinting for high-value operations
- Anomaly detection for unusual usage patterns
API7:2023 — Server-Side Request Forgery (SSRF)
- Risk: APIs that fetch remote resources based on user-supplied URLs without validating the target.
- How it works: Attacker provides internal URLs (
http://169.254.169.254/for cloud metadata,http://internal-service/) as input to API endpoints that fetch URLs. The server makes the request from its trusted network position, accessing internal resources. - Prevention:
- Validate and allowlist permitted URL schemes, hosts, and ports
- Block requests to internal/private IP ranges
- Don't follow redirects blindly
- Use network segmentation to limit server-side request scope
API8:2023 — Security Misconfiguration
- Risk: Insecure default configurations, unnecessary features, verbose errors, and missing security hardening.
- How it works: Stack traces in error responses reveal internal details. CORS allows all origins. TLS is outdated. API documentation is publicly accessible with full endpoint details. Unnecessary HTTP methods are enabled.
- Prevention:
- Automated configuration hardening and compliance checking
- Generic error responses (log details server-side)
- Restrictive CORS policies
- Current TLS configuration
- Disable unused features and methods
API9:2023 — Improper Inventory Management
- Risk: Outdated, deprecated, or undocumented API versions and endpoints that remain active without security monitoring.
- How it works: Old API versions (
/api/v1/) remain active alongside current versions (/api/v3/). The old versions may lack security controls added to newer versions. Shadow APIs — endpoints created during development that were never documented — persist in production. - Prevention:
- Comprehensive API inventory including all versions
- Automated API discovery to find shadow APIs
- Decommission deprecated versions with defined timelines
- Apply consistent security controls across all API versions
- Documentation requirements for all API endpoints
API10:2023 — Unsafe Consumption of APIs
- Risk: Trusting data from third-party APIs without validation, enabling attacks through the supply chain.
- How it works: Your API consumes data from a partner API and processes it without validation. If the partner API is compromised or returns malicious data, your application processes it as trusted input — potentially enabling injection, SSRF, or data corruption.
- Prevention:
- Validate and sanitize all data from third-party APIs
- Don't trust third-party API responses more than user input
- Implement timeouts and circuit breakers for external API calls
- Monitor third-party API behavior for anomalies
- Maintain a secure transport channel (TLS) for all external API communication
How SeqOps fits
SeqOps doesn't test APIs. It checks the cloud and server infrastructure your APIs run on, such as network exposure, access settings and unpatched software, so the platform underneath your APIs isn't the weak point.
Sources
Frequently asked questions
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a consensus-driven list of the most critical API security risks, updated in 2023. It covers: Broken Object/Function Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Unrestricted Access to Business Flows, SSRF, Security Misconfiguration, Improper Inventory Management, and Unsafe Third-Party API Consumption. It serves as a baseline for API security programs and testing.
What is the most dangerous OWASP API vulnerability?
API1: Broken Object Level Authorization (BOLA) — where APIs verify authentication but not authorization for specific resources. It's ranked #1 because it's extremely common, high-impact (enables mass data access), and often missed in testing. A single BOLA vulnerability can expose every user's data through ID enumeration.
How do you test for OWASP API Top 10 vulnerabilities?
Automated: use API security testing tools (Burp Suite, OWASP ZAP, 42Crunch) that specifically test for API Top 10 risks. Manual: API penetration testing focusing on authorization bypass, authentication flaws, and business logic abuse. Continuous: integrate API security scanning into CI/CD pipelines. Key test: "Can user A access user B's data?" covers the most critical vulnerability (BOLA).