The OWASP API Security Top 10 (2023 edition) is the industry-standard list of the most critical security risks for REST, GraphQL, gRPC, and WebSocket APIs. The ten categories cover broken object-level authorization (BOLA, the most common API vulnerability per Cloudflare and Salt Security data), broken authentication, broken property-level authorization, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs. Manual testing is required for authorization logic and chained exploits, since automated scanners miss these. Every finding maps to an OWASP API ID with proof-of-concept and a specific fix.
Your SaaS product is API-first. Your mobile app talks to APIs. Your integrations run on APIs. Your webhooks are APIs. If you’re a modern startup, your API is your product, and your API is your attack surface.
The OWASP API Security Top 10 is the definitive list of the most critical API security risks. Unlike the OWASP Web Top 10 (which focuses on web applications), the API Top 10 targets the specific vulnerabilities that affect API architectures, the ones your automated scanner won’t find.
What Is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a framework that identifies the ten most critical security risks specific to APIs. Published by the Open Web Application Security Project (OWASP), it serves as the industry standard checklist for API security testing.
The current version (2023) reflects real-world attack patterns against modern APIs: REST, GraphQL, gRPC, and WebSocket architectures.
The 10 Vulnerabilities: What Each Means for Your Product
API1: Broken Object-Level Authorization (BOLA)
What it is: Your API returns data for any object ID without checking if the requesting user is authorized to access that specific object.
Real example: GET /api/v1/orders/12345 returns order details. Change 12345 to 12346 and you see another customer’s order. The API checks if you’re logged in but not if order 12346 belongs to you.
Why scanners miss it: Every request returns a valid 200 response. The scanner sees “request succeeded” but can’t know that the data belongs to a different user.
What to test: For every API endpoint that takes an object ID, test with IDs belonging to other users, other tenants, and other roles.
API2: Broken Authentication
What it is: Flaws in authentication mechanisms that allow attackers to compromise tokens, keys, or passwords, or to exploit implementation flaws to assume other users’ identities.
Real example: Password reset endpoint doesn’t rate-limit OTP attempts. Attacker brute-forces the 6-digit OTP in under an hour. Or: JWT tokens are signed with a weak secret that can be cracked offline.
What to test: Token generation, session management, password reset flows, OTP validation, JWT implementation, API key scoping.
API3: Broken Object Property-Level Authorization
What it is: The API exposes object properties that the user shouldn’t be able to read or modify. The endpoint is authorized, but specific fields within the response aren’t filtered by role.
Real example: GET /api/v1/users/me returns {"name": "John", "email": "john@example.com", "role": "user", "is_admin": false}. Attacker sends PATCH /api/v1/users/me with {"is_admin": true}, and it works because the API doesn’t restrict which fields can be updated.
What to test: Check if responses include sensitive fields (internal IDs, roles, permissions). Try modifying read-only fields via PUT/PATCH requests.
API4: Unrestricted Resource Consumption
What it is: The API doesn’t limit how much data a client can request or how many requests it can make, enabling denial-of-service or cost-based attacks.
Real example: GET /api/v1/products?limit=999999 returns your entire product catalog in one response. Or: no rate limiting on the login endpoint allows credential stuffing at scale.
What to test: Request pagination limits, rate limiting on all endpoints (especially auth), file upload size limits, query complexity limits (GraphQL).
API5: Broken Function-Level Authorization
What it is: The API has admin-level endpoints that regular users can access because authorization is only enforced on the frontend, not the API layer.
Real example: The admin dashboard UI hides the “Delete User” button from non-admins. But DELETE /api/v1/admin/users/123 works for any authenticated user because the API doesn’t check roles.
What to test: Discover admin API endpoints (through docs, JavaScript source, or path guessing) and call them with non-admin credentials.
API6: Unrestricted Access to Sensitive Business Flows
What it is: The API exposes business flows that can be automated and abused at scale: buying limited inventory, creating fake accounts, scraping data.
Real example: A ticket booking API allows automated bots to reserve all tickets in seconds, or a referral program API allows automated signup loops to farm credits.
What to test: Identify business-critical flows and test for automation abuse: rate limiting, CAPTCHA enforcement, business rule validation.
API7: Server-Side Request Forgery (SSRF)
What it is: The API accepts a URL as input and makes a server-side request to it, allowing attackers to scan internal networks, access cloud metadata, or reach internal services.
Real example: POST /api/v1/import accepts a URL to fetch data from. Attacker submits http://169.254.169.254/latest/meta-data/iam/, and the API fetches AWS instance credentials.
What to test: Any endpoint that accepts URLs, webhooks, file imports from URLs, or image fetching from external sources.
API8: Security Misconfiguration
What it is: Missing security headers, verbose error messages, unnecessary HTTP methods enabled, CORS misconfiguration, default credentials.
Real example: API returns full stack traces in error responses, exposing internal file paths, database names, and framework versions. Or: CORS allows * origin with credentials.
What to test: Error handling, CORS configuration, HTTP methods (OPTIONS check), security headers, debug endpoints left in production.
API9: Improper Inventory Management
What it is: Old API versions, undocumented endpoints, and shadow APIs that are still running in production without monitoring or security controls.
Real example: /api/v1/users has proper authorization. But /api/v0/users (the old version) is still running with no auth checks. Or: a staging API endpoint is accessible from the internet.
What to test: Version enumeration, path discovery, subdomain scanning, documentation vs reality comparison.
API10: Unsafe Consumption of APIs
What it is: Your API trusts data from third-party APIs without validation, allowing an attacker who compromises the third-party to attack your system through the integration.
Real example: Your payment webhook handler trusts the incoming payload without verifying the webhook signature. An attacker sends a fake “payment successful” webhook and gets free access.
What to test: Webhook signature validation, third-party API response validation, certificate pinning for outbound API calls.
What Automated Scanners Find vs What Manual Testing Finds
| Vulnerability | Automated Scanner | Manual Pentest |
|---|---|---|
| API1: BOLA | Cannot find | Primary focus |
| API2: Broken Auth | Partial (basic checks) | Full coverage |
| API3: Property-Level Auth | Cannot find | Primary focus |
| API4: Resource Consumption | Partial (rate limits) | Full coverage |
| API5: Function-Level Auth | Rarely | Primary focus |
| API6: Business Flow Abuse | Cannot find | Primary focus |
| API7: SSRF | Partial | Full coverage |
| API8: Misconfiguration | Finds most | Finds all |
| API9: Inventory Management | Partial (version scanning) | Deep discovery |
| API10: Unsafe Consumption | Cannot find | Tests integrations |
6 out of 10 API vulnerabilities cannot be found by automated tools. This is why manual API penetration testing is essential. Scanners cover the configuration layer, but humans cover the logic layer.
What Industry Data Shows About API Vulnerabilities
The OWASP API Top 10 is ordered by severity and exploitability, not by how often each category surfaces in real engagements. Industry data from major API security vendors and bug bounty platforms paints a clearer picture of which findings dominate.
BOLA is the most common API vulnerability across the industry. According to multiple sources:
- Cloudflare reports BOLA appears in about 40% of all API attacks, making it the most common API security threat
- Salt Security’s State of API Security Report 2025 found BOLA accounted for 27% of attacks observed across their customer environments
- The same Salt Labs report found 99% of organizations encountered API security issues in the past 12 months
- Salt also found that injection-style attacks combined with BOLA accounted for 37% of reported issues, with sensitive data exposure at 34% and authentication weaknesses at 29%
- BOLA has held the #1 position on the OWASP API Security Top 10 since 2019, across both the 2019 and 2023 editions
What this means in practice: when we test SaaS APIs, BOLA, broken authentication, and security misconfiguration are the categories we find most often. They are also the categories that automated scanners structurally cannot detect, because they require understanding the business context (who should access what, what counts as a valid session, what configuration is appropriate for production).
Why BOLA dominates: modern frameworks largely mitigate injection, SSRF, and mass assignment by default. Authorization is the one layer the framework cannot solve for you. Every API endpoint that returns user-specific data needs an explicit, server-enforced ownership check. Most teams write the check for the obvious endpoints and miss it on the less-obvious ones (admin panels, internal APIs, batch endpoints, search filters).
Why injection and SSRF still matter when they appear: they tend to be high severity and chain well with authorization gaps. A single SSRF that lets an attacker reach an internal admin API combined with weak BFLA on that API is full account takeover territory.
How We Test APIs
Our API Penetration Testing follows the OWASP API Security Testing Guide:
- API Discovery: map all endpoints, methods, parameters, and authentication mechanisms
- Authentication Testing: tokens, sessions, OAuth flows, API key scoping
- Authorization Testing: BOLA, BFLA, property-level access, role escalation
- Input Validation: injection, SSRF, file upload, query manipulation
- Business Logic: workflow abuse, rate limiting, payment flow manipulation
- Reporting: every finding mapped to OWASP API Top 10 with PoC and fix guidance
We test REST, GraphQL, and gRPC APIs. If you have API documentation (Swagger/OpenAPI, Postman collections), share it. It lets us test business logic flows, not just technical surface.
What It Costs
- Startup Pentest Plan: ₹74,999 for 1 API scope, 7 days
- Growth Pentest Plan: ₹1,79,999 for 2 scopes (e.g., API + web app), 10 days, SOC 2 evidence included
API pentesting is a separate scope from web application testing. Your web app frontend and your API backend are tested independently because they have different attack surfaces.
Get a free security snapshot to see your external API exposure, see our full testing methodology, or contact us to scope your API pentest.