API Security Testing: The Vulnerabilities Scanners Miss and Pentesters Find

Your web application scanner reports a clean bill of health. Your API gateway shows no anomalies. Your automated DAST tool completed its crawl without finding anything critical. And yet, when a penetration tester spends three days with your API, they find that any authenticated user can access any other user's data by incrementing an ID in the URL.

This is not a hypothetical scenario. It is the reality of API security testing in 2026: the vulnerabilities that matter most are the ones that automated tools are fundamentally incapable of detecting. This guide explains why, walks through the OWASP API Top 10 with real-world context, and provides a methodology for testing APIs the way attackers actually attack them.

Why scanners fail at API security

Automated scanners are built to detect known vulnerability patterns: SQL injection in input fields, cross-site scripting in reflected parameters, missing security headers, outdated software versions. These are technical problems with technical signatures that tools can match against.

The most critical API vulnerabilities are not technical problems. They are business logic problems. They require understanding what the application is supposed to do and testing what happens when those rules are violated. A scanner cannot determine whether User A should be able to see User B's invoice. It does not know what a valid business workflow looks like, so it cannot identify when that workflow can be abused.

Consider the difference: a scanner can send a SQL injection payload to an API endpoint and observe whether the response indicates successful injection. That is pattern matching. But determining whether the API endpoint at /api/v2/admin/export-users should be accessible to a user with the "viewer" role requires understanding the application's authorization model. No scanner has that context.

The OWASP API Top 10: what each one means in practice

The OWASP API Security Top 10 is the industry standard taxonomy for API-specific vulnerabilities. Here is each category with the real-world context that matters for testing.

API1: Broken Object Level Authorization (BOLA)

BOLA is the single most common critical vulnerability in API penetration tests. The pattern is simple: an API returns data based on an object identifier (user ID, invoice number, document reference), and the API verifies that the requester is authenticated but does not verify that the requester is authorized to access that specific object.

Testing for BOLA requires two authenticated sessions representing different users. The tester takes object identifiers from User A's responses and submits them in User B's requests. If User B can access User A's objects, the authorization model is broken. This cross-account testing is something scanners cannot perform because they operate in a single authentication context.

API2: Broken Authentication

Weak or missing authentication mechanisms allow unauthorized API access. This includes JWT implementation flaws (weak signing secrets, algorithm confusion, missing expiration), API keys exposed in client-side code or URL parameters, missing authentication on endpoints that should require it, and password reset flows that leak information or allow account takeover.

API3: Broken Object Property Level Authorization

This is the more granular cousin of BOLA. Instead of accessing another user's entire object, the attacker can read or modify specific properties they should not have access to. A user update endpoint might accept a "role" field in the request body that the frontend never sends but the backend happily processes, allowing a standard user to grant themselves admin privileges. This is also called mass assignment.

API4: Unrestricted Resource Consumption

APIs without rate limiting or resource controls are vulnerable to brute force attacks, denial of service, and resource exhaustion. A login endpoint without rate limiting allows credential stuffing at scale. A search endpoint without pagination limits allows extraction of the entire database. An upload endpoint without size restrictions allows storage exhaustion.

API5: Broken Function Level Authorization

Standard users can access admin-level API endpoints by guessing or discovering URLs. This is distinct from BOLA in that it is about function-level access (can this user call this endpoint?) rather than object-level access (can this user access this specific record?). We test this by building an authorization matrix: every endpoint tested against every user role.

API6: Unrestricted Access to Sensitive Business Flows

Legitimate business features that can be automated and abused at scale: purchasing limited-inventory items, creating accounts for spam, submitting reviews, claiming promotional offers. The API works exactly as designed; the vulnerability is in the lack of controls against automated abuse.

API7: Server Side Request Forgery (SSRF)

APIs that accept URLs as input parameters can be tricked into making requests to internal systems, cloud metadata endpoints, or other services the attacker cannot reach directly. In cloud environments, SSRF to the metadata endpoint (169.254.169.254) can expose IAM credentials that grant broad access to cloud resources.

API8: Security Misconfiguration

This is the one category that scanners detect well: verbose error messages revealing stack traces, unnecessary HTTP methods enabled, missing CORS restrictions, default credentials, debug endpoints exposed in production, and missing security headers. Important to fix, but rarely the path to a critical breach.

API9: Improper Inventory Management

Old API versions remain accessible alongside current versions. Staging environments are publicly reachable. Documentation endpoints expose internal API schemas. Deprecated endpoints with known vulnerabilities continue to accept requests. You cannot secure APIs you do not know exist.

API10: Unsafe Consumption of APIs

Your application trusts data from third-party APIs without validation. If a partner API is compromised or returns malicious data, your application processes it without sanitization. This is especially relevant for applications that consume webhooks, payment processor callbacks, or data feeds from external sources.

Manual API testing methodology

Effective API penetration testing follows a structured methodology that goes far beyond running a scanner. Here is how we approach API assessments at Lorikeet Security.

Phase 1: Discovery and mapping

Before testing anything, we build a complete map of the API surface. This includes reviewing API documentation (OpenAPI/Swagger specs, Postman collections), analyzing client-side JavaScript for hidden endpoints, examining mobile app traffic for undocumented API calls, testing for old API versions (/api/v1/ when /api/v2/ is current), and checking for administrative or internal endpoints that are publicly accessible.

Discovery often reveals endpoints that the development team has forgotten about. These forgotten endpoints are frequently the least secured because they were never included in security reviews or testing cycles.

Phase 2: Authentication and session testing

We thoroughly test every authentication mechanism: JWT signing strength and algorithm handling, token expiration and revocation, session fixation and session hijacking, OAuth flow implementation, API key exposure and rotation, multi-factor authentication bypass scenarios, and password reset flow security.

Phase 3: Authorization matrix testing

This is the most labor-intensive and most valuable phase. We create a matrix mapping every discovered endpoint against every user role. For an application with five roles and 150 endpoints, that is 750 individual authorization checks. We systematically verify that each role can only access the endpoints and data appropriate to its permission level.

Every cell marked "Deny" or "Own only" is a test case. When the actual behavior does not match the expected behavior, we have found an authorization vulnerability.

Phase 4: Business logic and abuse testing

This phase tests the application's business rules: Can a buyer approve their own purchase order? Can a discount code be applied multiple times? Can a user bypass a required workflow step by calling API endpoints out of sequence? Can a deleted or suspended account's token still access data? These tests require understanding how the application is supposed to work, which is why they must be performed manually.

Phase 5: Input validation and injection

Traditional injection testing adapted for API contexts: SQL injection through JSON parameters, NoSQL injection through MongoDB query operators, SSRF through URL input fields, command injection through file processing endpoints, and XML external entity (XXE) injection through XML-accepting endpoints.

GraphQL: a different attack surface entirely

GraphQL APIs require a fundamentally different testing approach than REST APIs. The single-endpoint architecture, query language flexibility, and schema-driven design introduce risks that REST-focused methodologies miss entirely.

Introspection as reconnaissance. If introspection is enabled in production, a single query reveals the entire API schema: every type, field, mutation, subscription, and relationship. This is the equivalent of handing an attacker complete API documentation. We find introspection enabled in production in the majority of GraphQL APIs we test.

Query depth and complexity attacks. GraphQL's nested query structure allows exponential resource consumption. A query requesting users who have orders which have products which have reviews which have authors can create millions of database queries from a single HTTP request. Without depth limits and complexity analysis, this is a trivial denial-of-service vector.

Batching bypasses rate limiting. GraphQL typically accepts arrays of operations in a single request. An attacker can batch thousands of login attempts, password guesses, or data queries into one HTTP request, bypassing rate limiting that is applied per-request rather than per-operation.

Resolver-level authorization gaps. Authorization checks at the query level do not protect nested data accessed through resolvers. A user authorized to view their own profile might traverse the relationship graph to access another user's private data through nested queries that the authorization layer does not inspect.

For organizations running GraphQL in production, we recommend dedicated testing that addresses these GraphQL-specific concerns alongside standard API security testing. Our AI-generated code security assessments also cover GraphQL implementations built with code generation tools, which frequently ship with insecure defaults.

What scanner-only testing actually costs you

Organizations that rely exclusively on automated scanning for API security are making an economic calculation that does not account for the real risks. A vulnerability scanner might cost $5,000 to $15,000 per year. A manual API penetration test starts at $7,500. The scanner is cheaper on paper.

But consider what the scanner misses. A BOLA vulnerability that exposes customer data could result in breach notification costs, regulatory fines, customer churn, and reputational damage measured in hundreds of thousands or millions of dollars. The $7,500 pentest that catches it before an attacker does is not a cost. It is insurance with a clearly defined return.

The right approach is not scanner or pentest. It is both. Use automated scanning for continuous coverage of technical vulnerabilities and configuration issues. Use manual penetration testing for the business logic, authorization, and abuse-case vulnerabilities that scanners cannot find. Lorikeet's Offensive Security Bundle at $37,500 per year includes both: quarterly vulnerability scanning alongside dedicated web, API, and network penetration tests performed by experienced consultants.

For organizations that need a standalone API assessment, our API penetration tests start at $7,500 and include full OWASP API Top 10 coverage, authorization matrix testing, business logic testing, and a detailed report with remediation guidance your development team can act on immediately.

Securing your APIs: the practical checklist

Whether you are building APIs or testing them, these controls address the vulnerabilities we find most frequently in production environments.

• Implement object-level authorization on every endpoint. Every request that accesses a specific object must verify that the authenticated user has permission to access that specific object. Authentication alone is not sufficient.
• Use an allowlist for request body fields. Explicitly define which fields each endpoint accepts. Reject unexpected fields to prevent mass assignment attacks.
• Enforce rate limiting per-user and per-operation. Apply limits at the API operation level, not just the HTTP request level. This is critical for GraphQL APIs where batching can bypass request-level limits.
• Return only necessary data in responses. Use response schemas to enforce field filtering. Never return full database objects when the client needs only a subset of fields.
• Disable GraphQL introspection in production. Implement query depth limits and complexity analysis. Suppress field suggestions in error messages.
• Validate all input server-side. Never trust client-side validation. Validate types, lengths, ranges, formats, and business rules on every request.
• Maintain a complete API inventory. Document every endpoint including internal, partner-facing, and legacy versions. Decommission endpoints that are no longer needed.
• Log all API access with sufficient detail. Capture authenticated user, endpoint, parameters, and response status for every request. These logs are essential for incident detection and forensic investigation.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.