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.
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.