OWASP API Security Top 10 (2023): Every Risk Explained with Fixes

Quick Overview: APIs are a primary target for attackers, and many of the most serious breaches start from overlooked security flaws. This blog breaks down the OWASP API Security Top 10 (2023), explaining each risk, how attackers exploit it, why some vulnerabilities are difficult to detect, and the practical fixes security teams can implement. It also covers testing approaches, detection challenges, BOLA vs. BFLA, and compliance considerations you must know about.

The OWASP API Security Top 10 is a ranked list of the most critical API vulnerabilities, maintained by the Open Worldwide Application Security Project and updated in September 2023. BOLA (Broken Object Level Authorization) tops the list and accounts for roughly 40% of all API attacks, according to Salt Security's 2024 State of API Security Report. The 2023 update added three categories the 2019 list did not have, specifically SSRF and two business logic abuse categories, because these are now where the majority of undetected API attacks happen.

This guide covers all ten risks from the 2023 edition: what each one is, how attackers exploit it, and how an automated API pentesting tool uncovers flaws. We also cover the detection difficulty of each risk. Four of the ten cannot be found by pattern-matching scanners, and knowing which four tells you where your testing gaps actually are.

Don’t let hackers exploit your APIs. Detect API security risk 10× faster with ZeroThreat. Start For FREE

What Is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a ranked list of the ten most critical API security vulnerabilities published by the Open Worldwide Application Security Project (OWASP). The current edition was released in September 2023. It is drawn from real-world penetration testing data, bug bounty research, and community submissions, and it is updated when attack patterns against APIs shift materially.

OWASP (Open Worldwide Application Security Project) is a nonprofit foundation that publishes free security research, tools, and guidance for security teams and developers. Its API Security Top 10 is the most widely referenced standard for API security risk.

Key distinction: The OWASP API Security Top 10 is not the same as the OWASP Web Application Top 10. The web application list targets browser-facing vulnerabilities such as XSS and insecure deserialization. The API list focuses on authorization logic failures, business flow exploitation, and behavioral vulnerabilities that rule-based scanners cannot catch with signatures alone.

What Changed in the OWASP API Security Top 10 2023 Update

Three New Categories were Added in the 2023 List

The 2023 update added Server-side Request Forgery (API7), Unrestricted Access to Sensitive Business Flows (API6), and Unsafe Consumption of APIs (API10). Their addition reflects two concrete shifts: cloud-hosted APIs have made SSRF attacks against internal infrastructure far more damaging, and automated bot abuse of valid business logic has become a primary attack vector that the 2019 list did not account for.

Two 2019 Categories Merged into One

Excessive Data Exposure (2019 API3) and Mass Assignment (2019 API6) were consolidated into Broken Object Property Level Authorization (2023 API3). Both vulnerabilities share the same root cause: the API does not enforce which properties a user can read or write, so OWASP correctly merged them into a single category with a unified remediation approach.

What Stayed at the Top

BOLA has held the number one position since 2019. Broken Authentication (API2) has held number two. Their persistence is not an oversight. Object-level access control is hard to enforce consistently at scale, and authentication state management in stateless REST APIs creates gaps that attackers find reliably. These two categories together account for the majority of serious API data breaches.

OWASP API Security Top 10 (2023): Reference Table with Detection Difficulty

The table below maps all 10 OWASP API risks to their real-world attack pattern, how difficult each is to detect automatically, why scanners miss them, and how ZeroThreat covers each one.

Detection Difficulty Key:

• Easy = Configuration analysis covers it.
• Medium = Active authenticated testing required.
• Hard = Role and context awareness required.
• Very Hard = Multi-step simulation required. Pattern-matching scanners miss these.

Test your production endpoints against all ten OWASP attack categories with just a click. Assess API Security

The 10 OWASP API Security Risks Explained

API1: Broken Object Level Authorization (BOLA)

Detection difficulty: Very Hard

BOLA occurs when an API returns or modifies data based on an object identifier in the request without verifying whether the requesting user has permission to access that specific object. The attack is simple: GET /api/orders/1042 returns your order. GET /api/orders/1043 returns someone else's data, using your token. No malformed request. No injection payload. The API is functioning as designed. The authorization check is absent.

BOLA accounts for roughly 40% of all API attacks, according to Salt Security. It has ranked first since 2019 because it is invisible to network-layer inspection and unlimited in impact. In a healthcare API, an attacker who finds BOLA can enumerate every patient record. In a financial API, every account balance and transaction. The data exposure scales linearly with the ID range.

Why scanners miss it: BOLA requires business context, specifically knowing which user owns which object. Pattern-matching scanners see a 200 response and pass the endpoint. They cannot distinguish an authorized object response from an unauthorized one without knowing the relationship between the requesting user and the object.

How to fix it: Enforce object-level authorization checks server-side on every endpoint that retrieves or modifies data objects. Validate user permissions before every read, update, or delete operation. Apply least-privilege roles. Log and monitor access patterns for enumeration behavior.

API2: Broken Authentication

Detection difficulty: Medium

Broken authentication covers failures in how APIs verify identity: tokens with insufficient entropy, sessions that remain valid after logout, missing rate limiting on login endpoints that enables credential stuffing, JWT validation failures, and API keys embedded in mobile apps or JavaScript bundles. Stolen tokens and credential stuffing are now the dominant initial access vectors in API attacks.

Attackers rarely need to break encryption. They find tokens in public repositories, JavaScript files, or mobile app binaries and replay them against production APIs. The gap is not cryptographic. It is lifecycle management. A token that never expires or that remains valid after a logout event is an open door regardless of how strong the signature algorithm is.

How to fix it: Short-lived tokens with proper expiry. Hardened authentication flows with rate limiting on credential endpoints. MFA for sensitive operations. Session invalidation on logout confirmed server-side. Audit API keys in all client-facing surfaces.

API3: Broken Object Property Level Authorization

Detection difficulty: Hard | New category merging 2019 API3 + API6

This category covers two related failures with a shared root cause. In the read direction: the API returns more fields than the requesting user should see (the former Excessive Data Exposure). In the right direction: the API accepts more fields in a request body than the user should be allowed to modify, enabling privilege escalation through mass assignment.

The mass assignment pattern is direct. A user update endpoint is designed to accept name and email. An attacker adds 'role': 'admin' to the request body. If the API passes the full body to the data layer without field filtering, the attacker has elevated their own privileges with a single extra JSON key. No injection. No cryptography. One field.

How to fix it: Define strict request body schemas and reject undocumented fields. Use allowlists for properties that each role can read or write. Never bind incoming data directly to internal objects without validation.

API4: Unrestricted Resource Consumption

Detection difficulty: Medium

This risk covers the absence of limits on how much of a server's resources a single client can consume: no per-user rate limits, no payload size caps, no concurrency controls, no timeouts on long-running operations. Attackers exhaust resources without sending any malicious payload. They just send a lot of legitimate requests simultaneously.

Operational impact rather than data theft is the goal. A competitor running a botnet against a product search endpoint at 50,000 requests per minute does not need to steal data. They make the service unavailable during peak hours at near-zero cost. And per-user authenticated rate limits are almost always weaker than per-IP limits. The authenticated context is where the real exposure sits.

How to fix it: Implement rate limiting at both the IP and authenticated-user level. Set hard limits on payload sizes and request counts. Add timeouts to all API operations, especially those that hit databases or external services.

API5: Broken Function Level Authorization (BFLA)

Detection difficulty: Hard

BFLA occurs when an API does not properly enforce which roles can call which functions. The typical attack: a standard user changes the HTTP method from GET to DELETE on an admin endpoint, or prepends /admin/ to a standard path, and gets a 200 instead of a 403. The authorization logic exists for the documented path but not for its method variants or administrative shadow.

BFLA is distinct from BOLA. BOLA is about accessing another user's data. BFLA is about accessing functions your role should not be allowed to execute at all. An attacker exploiting BFLA does not need another user's object ID. They need to find the function, and undocumented admin paths are often discovered through API response headers, JavaScript bundles, or error messages.

How to fix it: Enforce function-level authorization checks on every endpoint, not just documented paths. Apply the same checks across all HTTP methods. Deny by default and explicitly allow only the functions each role requires.

API6: Unrestricted Access to Sensitive Business Flows

Detection difficulty: Very Hard | New in 2023

This category covers attacks on valid business logic, not code-level flaws. Bots that buy out all available inventory before human customers can. Automated systems creating thousands of free trial accounts using disposable email addresses. Price manipulation through coupon or discount logic. Account takeover through credential stuffing on login endpoints with no alerting or lockout.

No payload in these attacks is malformed. Every request is technically valid. The API is functioning as documented. The vulnerability is the absence of controls distinguishing legitimate human usage from automated abuse at scale. Most automated scanners have no way to make that distinction because they test requests, not behaviors.

How to fix it: Identify critical business flows and implement controls that recognize automated abuse patterns: device fingerprinting, behavioral rate limits, CAPTCHA on sensitive flows, anomaly detection on high-value operations.

API7: Server-Side Request Forgery (SSRF)

Detection difficulty: Medium | New in 2023

SSRF forces a server to make outbound HTTP requests to a URL controlled by the attacker. The vulnerable pattern: an API accepts a URL parameter (for webhook registration, image fetching, or URL preview generation) and makes a server-side request to that URL without validation. An attacker points it at the AWS instance metadata endpoint (169.254.169.254) and receives cloud credentials, IAM roles, and internal network topology in the response.

SSRF was added in 2023 specifically because cloud-hosted APIs have made this attack more damaging than it was in 2019. The internal infrastructure accessible through cloud metadata was not reachable by equivalent attacks in on-premise architectures. The addition reflects where production APIs actually run today.

How to fix it: Validate and sanitize all user-controlled URL inputs. Use allowlists for permitted outbound destinations. Block requests to private IP ranges, loopback addresses, and cloud metadata endpoints at the network layer.

API8: Security Misconfiguration

Detection difficulty: Easy

Security misconfiguration is the most detectable category on the list. Swagger UI left enabled in production. CORS set to wildcard (*). Debug mode active. Default credentials unchanged. HTTP responses exposing server version and stack. Missing TLS. Excessive IAM permissions on cloud API functions. Attackers scan for these configurations specifically because they are trivial to identify and frequently exploitable without authentication.

An exposed /swagger endpoint gives an attacker the complete API surface before they send a single attack request. Wildcard CORS combined with a sensitive endpoint is cross-origin data theft by design. These are not exotic vulnerabilities. They are deployment failures that should not survive a basic security scan.

How to fix it: Disable all documentation and debug endpoints in production. Set restrictive CORS policies. Remove default credentials before deployment. Validate TLS configuration. Regularly diff configuration between staging and production environments.

API9: Improper Inventory Management

Detection difficulty: Medium

APIs accumulate attack surface over time. Version 1 remains active because migrating all clients is slow. A testing endpoint was never removed from production. A mobile app still calls an internal API the team considers deprecated but never actually disabled. These forgotten endpoints are unpatched, unmonitored, and often not covered by the security testing scope because they are not in the documentation.

Attackers target them specifically. A shadow endpoint does not appear in Swagger, does not receive patches, and does not trigger alerts in monitoring configured to watch documented paths. It is, from the attacker's perspective, an unguarded side entrance that the organization does not know they are leaving open.

How to fix it: Run API discovery before every security test to identify shadow, zombie, and undocumented endpoints. Maintain a formal API inventory. Set a deprecation policy with actual enforcement dates. Scan for version enumeration on every assessed target.

API10: Unsafe Consumption of APIs

Detection difficulty: Very Hard | New in 2023

Applications that consume third-party APIs often trust the data they receive without validation. The assumption: if the data came from our payment provider's API, it is safe to process. That assumption fails when the third-party API is compromised, when a man-in-the-middle modifies the response in transit, or when the integration partner's API contains its own vulnerabilities that can be triggered through your application.

The attack works by corrupting or manipulating what a third-party API returns to your application. If your application passes that response directly to a database query, HTML renderer, or internal service without sanitization, the attacker has used your trusted integration as the delivery mechanism.

How to fix it: Validate and sanitize all data received from third-party APIs before passing it to downstream systems. Do not inherit the security posture of your integration partners. Test the trust boundary of every external API your application consumes.

Unlock advanced, high-signal API pentesting capabilities that match your security operational scale. View Pricing

How to Test for OWASP API Security Top 10 Vulnerabilities

Four of the ten OWASP API Security Top 10 categories require capabilities that pattern-matching scanners do not have:

• BOLA (API1): detection requires testing the same endpoint with multiple user tokens and comparing responses. A scanner testing with one user context cannot tell whether it is receiving data it should not be authorized to see.
• BFLA (API5): detection requires testing endpoints across multiple user roles, varying HTTP methods, and exploring path variants beyond documented routes. No payload signature exists; the flaw is an absent check.
• Unrestricted Business Flows (API6): detection requires simulating multi-step workflows at machine scale to observe whether rate limiting and behavioral controls exist. A single-request scanner cannot replicate the attack.
• Unsafe Consumption (API10): detection requires testing the trust boundary between your application and third-party APIs, which is outside the attack surface that standard DAST tools consider.

The remaining six categories fall into Medium or Easy detection difficulty and are within the scope of authenticated DAST scanning. A reasonable security testing program automates coverage of the six detectable categories continuously and schedules manual or specialist testing for the four harder ones.

BOLA vs BFLA: What is the Difference?

These two categories are the most commonly confused in the OWASP API Top 10. They share a name structure, and both involve authorization failures, but the attack and the fix are different.

The practical rule: if the attack involves accessing someone else's data by changing an ID in the request, it is BOLA. If the attack involves calling a function your role should not be able to reach, it is BFLA. Both require authenticated multi-role testing to detect.

Why Authenticated Scanning Covers What Unauthenticated Scanning Misses

The majority of API attack surface sits behind authentication. BOLA, BFLA, and business logic flaws only exist in contexts where users are logged in and making authorized requests. An unauthenticated scan tests the public surface only. It misses the access control logic that governs 80% to 90% of a typical API's functionality.

Running authenticated scans requires capturing login flows, managing session state across multi-step requests, and replaying authentication sequences without triggering MFA prompts. ZeroThreat's Chrome Recorder Extension handles this by recording login flows directly in the browser and storing them for reuse across scheduled scans and CI/CD integrations.

How Automated API Pentesting Covers the OWASP Top 10

ZeroThreat covers all 10 OWASP API Security categories in a single automated scan. Scans typically complete in 30 minutes to 2 hours for mid-sized APIs, with results mapped to OWASP API categories, severity levels, and code-level remediation guidance. The platform supports REST, GraphQL, gRPC, and SOAP APIs and generates compliance-ready reports for HIPAA, PCI-DSS, and GDPR.

For the four Very Hard categories, ZeroThreat uses behavioral testing approaches: multi-user session comparison for BOLA, cross-role function access testing for BFLA, Playwright-based Application Journey testing for business flow abuse, and third-party integration response validation for unsafe consumption.

OWASP API Top 10 Testing Checklist

Use this checklist to verify your API security testing covers all 10 OWASP API categories. Each row defines what to verify and the testing method required.

All 10 checklist items are covered in a ZeroThreat automated API pentesting scan. The free plan includes one scan credit per month. No configuration required.

OWASP API Top 10 and Regulatory Compliance

PCI DSS v4.0 requires penetration testing that covers OWASP API risks for applications handling cardholder data. HIPAA security risk assessments are expected to identify vulnerabilities equivalent to OWASP API Top 10 categories when patient data is exposed via APIs. SOC 2 Type II auditors increasingly ask for evidence of API security testing that demonstrates OWASP coverage.

Scan reports that map findings directly to OWASP API Security categories are the format auditors understand. ZeroThreat generates compliance-ready PDF reports mapped to OWASP, HIPAA, PCI-DSS, GDPR, and ISO 27001, downloadable from the Professional plan and above.

Struggling to secure complex, undocumented APIs? Talk directly with ZeroThreat experts. Contact Us

Test Your APIs Against All 10 OWASP Categories

The OWASP API Security Top 10 describes where APIs are actually being attacked today, not theoretical risks. Four of the ten categories require behavioral, multi-step, or multi-user testing that standard scanners do not perform. Those four are where most undetected API breaches originate.

ZeroThreat runs automated penetration tests covering all 10 OWASP API categories. Every finding is validated for exploitability before it surfaces in your report. Scan results map directly to OWASP categories with code-level remediation guidance included.

The free plan includes one scan credit per month. No configuration required. Enter your API URL and start the scan.