OWASP API Security Top 10 Explained: Every Vulnerability and How to Test (2026)

Table of Contents

1. Introduction
2. What Is the OWASP API Security Top 10?
3. Why the OWASP API Security Top 10 Matters
4. The Ten Vulnerability Categories
5. How to Build an OWASP API Testing Program
6. Tools for OWASP API Security Testing
7. Real-World Example
8. Common Challenges
9. Best Practices
10. OWASP API Security Testing Checklist
11. FAQ
12. Conclusion

---

Introduction

APIs have become the primary target for sophisticated attackers, yet most security testing programs still focus on traditional web application vulnerabilities like cross-site scripting and CSRF. The disconnect is staggering — Akamai reported that API-targeted attacks grew by over 100% year-over-year through 2025, while many organizations still rely on OWASP's general web application Top 10 for their API security strategy.

The problem is that APIs face fundamentally different risks than traditional web applications. An API does not have a browser enforcing same-origin policies. It does not have form-based input that frameworks automatically sanitize. APIs expose raw data and business logic directly, and the vulnerabilities that matter most — broken authorization, excessive data exposure, mass assignment — barely appear in the general OWASP Top 10.

The OWASP API Security Top 10 exists to close this gap. It is the definitive checklist for API security testing programs, providing a structured approach to the vulnerabilities that actually compromise APIs in the real world. This guide breaks down each category, explains how to test for it, and shows how to build a comprehensive testing program around it.

---

What Is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a consensus document developed by security researchers, practitioners, and industry experts under the Open Web Application Security Project umbrella. First published in 2019 and updated in 2023, it identifies the ten most impactful security risks specific to APIs based on real-world breach data, bug bounty findings, and expert analysis.

Unlike the general OWASP Top 10 which covers broad web application security, the API Security Top 10 addresses risks unique to programmatic interfaces: object-level authorization failures that let users access each other's data, mass assignment vulnerabilities where APIs accept fields they should not, and server-side request forgery through API parameters.

The ten categories are:

1. API1 — Broken Object Level Authorization (BOLA)
2. API2 — Broken Authentication
3. API3 — Broken Object Property Level Authorization
4. API4 — Unrestricted Resource Consumption
5. API5 — Broken Function Level Authorization
6. API6 — Unrestricted Access to Sensitive Business Flows
7. API7 — Server Side Request Forgery (SSRF)
8. API8 — Security Misconfiguration
9. API9 — Improper Inventory Management
10. API10 — Unsafe Consumption of APIs

Each category represents a class of vulnerabilities, not a single bug. Effective testing requires understanding the attack patterns within each category and building test cases that cover them systematically across every API endpoint.

---

Why the OWASP API Security Top 10 Matters

Industry Standard for Compliance

Regulatory frameworks including PCI DSS, SOC 2, and ISO 27001 reference OWASP standards as testing baselines. When auditors evaluate your API security program, they expect to see coverage mapped to OWASP categories. Having a structured testing program aligned to the API Security Top 10 streamlines compliance and reduces audit friction.

Focuses Testing on Real-World Risks

The API Security Top 10 is derived from actual breach data and vulnerability reports, not theoretical risks. BOLA (API1) is ranked first because it is the vulnerability most frequently exploited in real API breaches. By prioritizing testing according to the Top 10 ranking, teams focus resources where attackers actually strike.

Common Language Across Teams

The Top 10 provides a shared vocabulary that developers, QA engineers, security teams, and management can use to discuss API risks. When a security test reports "API1 — BOLA vulnerability in the orders endpoint," every stakeholder understands the severity and the fix. This common language accelerates remediation.

Foundation for Automated Testing

Each OWASP API category maps to specific, automatable test patterns. BOLA tests can be generated systematically for every resource endpoint. Authentication tests follow predictable patterns. This structure makes the Top 10 an ideal framework for building automated API security test suites that run in CI/CD pipelines.

---

The Ten Vulnerability Categories

API1 — Broken Object Level Authorization (BOLA)

BOLA occurs when an API does not verify that the authenticated user is authorized to access the specific resource they requested. An attacker modifies object identifiers — user IDs, order IDs, document IDs — in API requests to access resources belonging to other users.

How to test: For every endpoint that accepts a resource identifier, authenticate as User A, capture a valid resource ID belonging to User A, then replay the request with a resource ID belonging to User B. The API should return 403 Forbidden. Automate this across all resource endpoints with parameterized test data.

API2 — Broken Authentication

Broken authentication encompasses weaknesses in the API's identity verification mechanisms: weak token generation, missing token validation, credential stuffing vulnerability, insecure password reset flows, and session management failures.

How to test: Test with missing, expired, malformed, and revoked tokens. Verify that password reset tokens are single-use and time-limited. Check that JWT tokens validate signatures properly and reject modified payloads. Confirm rate limiting on login endpoints prevents brute-force attacks.

API3 — Broken Object Property Level Authorization

This combines the former "Excessive Data Exposure" and "Mass Assignment" categories. APIs may return object properties the user should not see (data exposure) or accept properties the user should not be able to set (mass assignment).

How to test: Compare API responses against the documented schema — flag any fields that contain internal or sensitive data not needed by the client. For mass assignment, send requests with extra properties (like role: "admin" or price: 0) and verify the API ignores unauthorized fields.

API4 — Unrestricted Resource Consumption

APIs without rate limiting or resource consumption controls are vulnerable to denial-of-service, brute-force attacks, and resource exhaustion through expensive queries or large file uploads.

How to test: Send rapid bursts of requests and verify 429 responses after the threshold. Test with extremely large request payloads, deeply nested JSON objects, and queries that request excessive data ranges. Verify that pagination is enforced and cannot be bypassed.

API5 — Broken Function Level Authorization

Function-level authorization failures occur when APIs do not properly restrict access to administrative or privileged functions. A regular user may be able to access admin endpoints by simply calling them directly.

How to test: Map all API endpoints and categorize them by required privilege level. Authenticate as a regular user and attempt to call every administrative endpoint. Verify that role-based access control is enforced at the API level, not just the UI level.

API6 — Unrestricted Access to Sensitive Business Flows

Some API endpoints expose business-critical flows — purchasing, booking, commenting — that attackers can abuse through automation even without traditional security vulnerabilities. Ticket scalping bots, automated account creation, and review manipulation exploit this category.

How to test: Identify business-critical flows and verify that anti-automation controls (CAPTCHA, rate limiting, device fingerprinting) are present. Test whether these controls can be bypassed through API calls that skip the frontend protections.

API7 — Server Side Request Forgery (SSRF)

SSRF occurs when an API accepts a URL or network address as input and makes server-side requests to that destination without proper validation. Attackers use this to scan internal networks, access cloud metadata services, or reach internal services.

How to test: For every parameter that accepts URLs, test with internal addresses (127.0.0.1, 169.254.169.254 for cloud metadata, internal hostnames), protocol handlers (file://, gopher://), and redirect chains that resolve to internal targets.

API8 — Security Misconfiguration

Security misconfiguration covers missing security headers, verbose error messages, unnecessary HTTP methods enabled, permissive CORS policies, default credentials, and missing TLS enforcement.

How to test: Scan all endpoints for security headers (Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy). Verify CORS does not allow wildcards on authenticated endpoints. Test that error responses do not include stack traces. Confirm only necessary HTTP methods are enabled.

API9 — Improper Inventory Management

Organizations often lose track of API versions, deprecated endpoints, and shadow APIs that remain accessible. Old API versions may lack security fixes applied to current versions, and undocumented endpoints may bypass security controls.

How to test: Scan for common API version patterns (/v1/, /v2/, /beta/, /internal/). Check that deprecated endpoints are actually disabled. Compare API gateway configurations against OpenAPI specifications to identify undocumented endpoints.

API10 — Unsafe Consumption of APIs

When your API consumes third-party APIs, it inherits their security risks. If a third-party API is compromised or returns malicious data, your API may process it without validation, leading to injection, data corruption, or security bypasses.

How to test: Identify all third-party API integrations and verify that your API validates and sanitizes data received from external sources. Test with mocked malicious responses from third-party APIs to verify your API handles them safely.

---

How to Build an OWASP API Testing Program

Building an OWASP-aligned testing program requires mapping each vulnerability category to automated and manual test activities across the development lifecycle:

Step 1 — API Inventory and Classification: Catalog all APIs with their authentication mechanisms, authorization models, and data sensitivity levels. This inventory drives test prioritization — APIs handling financial or personal data get comprehensive coverage first.

Step 2 — Automated Test Suite Creation: For each OWASP category, create automated test suites that run in CI/CD. BOLA tests, authentication tests, input validation tests, and configuration checks can all be automated. Generate these from OpenAPI specifications to ensure they stay current as APIs evolve.

Step 3 — DAST Integration: Configure OWASP ZAP or equivalent DAST tools to scan staging environments on every deployment, with scan policies tuned to the API Security Top 10 categories. Feed authenticated session tokens so the scanner can test beyond the login page.

Step 4 — Manual Penetration Testing: Schedule quarterly manual penetration tests focused on business logic vulnerabilities (API5, API6) that automated tools struggle to detect. Use the OWASP Testing Guide as the methodology framework.

Step 5 — Continuous Improvement: Track vulnerability findings by OWASP category over time. If BOLA findings keep recurring, invest in authorization middleware or framework-level fixes rather than endpoint-by-endpoint patching.

---

Tools for OWASP API Security Testing

OWASP ZAP provides the most comprehensive free coverage of the API Security Top 10, with scan policies that map directly to each vulnerability category. Its API scan mode accepts OpenAPI specifications to guide testing, and its active scan injects payloads covering injection, authentication bypass, and configuration issues.

For teams that need to generate OWASP-aligned tests automatically, Total Shift Left reads OpenAPI specifications and produces test suites covering BOLA, authentication, input validation, and data exposure — the categories that account for over 70% of real API breaches.

Combining automated scanning with REST API testing best practices creates a defense-in-depth strategy that covers both known vulnerability patterns and application-specific business logic.

---

Real-World Example

Problem: A healthcare SaaS company with 340 API endpoints underwent a SOC 2 audit and could not demonstrate systematic OWASP API Security Top 10 coverage. Their testing consisted of ad-hoc Postman collections and an annual penetration test. The auditor flagged insufficient security testing as a material finding, threatening their ability to close enterprise contracts.

Solution: The team built an OWASP-aligned API security testing program in four weeks:

1. Created an API inventory by parsing their API gateway configuration and OpenAPI specifications, classifying endpoints by data sensitivity and authentication requirements
2. Generated automated security tests from their OpenAPI specs using Total Shift Left, covering API1 (BOLA), API2 (Authentication), API3 (Data Exposure), and API4 (Rate Limiting) categories
3. Integrated OWASP ZAP into their staging deployment pipeline with scan policies covering all ten categories
4. Established a quarterly penetration testing schedule focused on API5 (Function-Level Authorization) and API6 (Business Logic) categories
5. Created a coverage dashboard mapping test results to OWASP categories for audit evidence

Results:

• Achieved full OWASP API Security Top 10 test coverage within 30 days
• Passed the SOC 2 re-audit with the security testing finding resolved
• Discovered 17 previously unknown vulnerabilities: 4 BOLA, 6 data exposure, 3 authentication, 2 rate limiting, 2 misconfiguration
• Reduced mean time to detect security vulnerabilities from 90+ days to under 24 hours
• Security testing now runs automatically on every deployment with no manual intervention

---

Common Challenges

Mapping Tests to OWASP Categories

Teams struggle to determine which specific tests cover which OWASP categories, making it difficult to identify coverage gaps and report compliance.

Solution: Create a coverage matrix that maps each API endpoint to the OWASP categories that apply, then track which categories have automated tests, DAST coverage, and manual test coverage. Use this matrix to identify and prioritize gaps.

Business Logic Vulnerabilities Resist Automation

API5 (Function-Level Authorization) and API6 (Business Logic) vulnerabilities require understanding application context that automated tools lack.

Solution: Focus automation on the categories where it excels (API1-API4, API7-API8) and reserve manual penetration testing bandwidth for business logic categories. Document business rules that testers need to understand for effective manual testing.

API Specification Drift

Tests generated from OpenAPI specifications become stale when APIs change without updating the specification, creating false security from outdated tests.

Solution: Implement contract testing that fails the build when API behavior diverges from the specification. This forces specifications to stay current, which keeps security tests accurate.

Prioritizing Remediation Across Categories

When security testing reveals vulnerabilities across multiple OWASP categories, teams struggle to prioritize fixes effectively.

Solution: Prioritize by exploitability and impact. BOLA (API1) and Broken Authentication (API2) vulnerabilities should be fixed immediately as they are most frequently exploited. Configuration issues (API8) are typically quick wins. Schedule business logic fixes (API5, API6) for the next sprint.

---

Best Practices

• Map every endpoint to applicable OWASP categories: Not every category applies to every endpoint — create a matrix that identifies which categories are relevant for each API
• Automate the automatable: API1 (BOLA), API2 (Authentication), API3 (Data Exposure), API4 (Rate Limiting), and API8 (Misconfiguration) can all be tested automatically on every build
• Test authorization with multiple user contexts: Maintain test accounts for every role in your system and systematically test cross-role access on every endpoint
• Generate tests from specifications: Use OpenAPI specifications as the source of truth for security test generation to ensure tests stay current with API changes
• Run DAST in staging, not production: Active security scanning generates malicious payloads — run these against staging environments with production-like configurations
• Track vulnerability trends by category: Monitor which OWASP categories produce the most findings over time to identify systemic weaknesses that need architectural fixes
• Include OWASP coverage in definition of done: No API feature is complete until its security tests cover all applicable OWASP categories
• Maintain a living API inventory: Shadow APIs and deprecated versions are the most common entry point for attackers — keep your inventory current
• Test third-party API consumption: Validate and sanitize data from every external API you consume, and test your error handling when third-party APIs return unexpected data
• Combine automated and manual testing: Automated tools cover known patterns efficiently, but manual testing catches business logic flaws that scanners miss

---

OWASP API Security Testing Checklist

• ✔ Create and maintain a complete API inventory with data sensitivity classifications
• ✔ Map each endpoint to applicable OWASP API Security Top 10 categories
• ✔ Implement automated BOLA tests for every endpoint that accepts resource identifiers
• ✔ Test authentication flows: missing tokens, expired tokens, malformed tokens, revoked sessions
• ✔ Verify API responses do not include sensitive fields beyond what the client requires
• ✔ Test mass assignment by sending requests with unauthorized properties
• ✔ Validate rate limiting on authentication endpoints, sensitive operations, and data-heavy queries
• ✔ Test function-level authorization: regular users cannot access admin endpoints
• ✔ Scan for SSRF vulnerabilities on all parameters that accept URLs or network addresses
• ✔ Verify security headers, CORS policies, TLS enforcement, and error response sanitization
• ✔ Check for deprecated API versions and undocumented endpoints that remain accessible
• ✔ Validate that third-party API data is sanitized before processing

---

FAQ

What is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a standard awareness document published by the Open Web Application Security Project that identifies the ten most critical API security risks. It serves as a baseline for API security testing programs, covering vulnerabilities like broken object-level authorization, broken authentication, excessive data exposure, and injection attacks.

What is broken object-level authorization (BOLA)?

Broken object-level authorization (BOLA) is the most critical API vulnerability where an attacker manipulates resource identifiers in API requests to access other users' data. For example, changing /api/users/123/orders to /api/users/456/orders to view another user's orders. It is ranked API1 in the OWASP API Security Top 10.

How do you test for OWASP API Security Top 10 vulnerabilities?

Test for OWASP API Security Top 10 vulnerabilities using a combination of automated DAST tools like OWASP ZAP for scanning, manual penetration testing for logic flaws, SAST tools for code-level analysis, and automated test suites that systematically validate authentication, authorization, input validation, and data exposure for every endpoint.

What is the difference between OWASP Top 10 and OWASP API Security Top 10?

The OWASP Top 10 covers general web application security risks including XSS and CSRF, while the OWASP API Security Top 10 focuses specifically on API-related vulnerabilities like broken object-level authorization, mass assignment, and improper inventory management. APIs face unique risks that the general web Top 10 does not adequately address.

How often should you test for OWASP API vulnerabilities?

OWASP API vulnerability testing should be continuous — automated security tests running in CI/CD on every deployment, DAST scans on every staging release, and comprehensive manual penetration tests quarterly. Critical endpoints handling authentication and sensitive data should be tested on every code change.

---

Conclusion

The OWASP API Security Top 10 provides the essential roadmap for API security testing. By systematically testing each category with a combination of automated tools, generated test suites, and targeted manual testing, teams can close the security gaps that attackers exploit most frequently and build compliance evidence that satisfies auditors.

Start mapping your APIs to the OWASP API Security Top 10 today. Try Total Shift Left free to automatically generate security tests aligned to OWASP categories from your OpenAPI specifications.

---

Related: API Testing: The Complete Guide | API Security Testing: Complete Guide | How to Test API Authentication and Authorization | JWT Authentication Testing Guide | OAuth API Testing Best Practices | REST API Testing Best Practices | Automated Testing in CI/CD