Executive Summary
APIs now account for over 80% of internet traffic and have become the primary attack surface for modern applications. Yet most organizations still treat API security as an afterthought — running occasional DAST scans that miss business logic flaws, authentication vulnerabilities, and schema drift. The result is a widening gap between the pace of API development and the security team’s ability to keep up.
This whitepaper explores how Continuous Threat Exposure Management (CTEM) principles applied to API security testing can close that gap — delivering continuous assurance without slowing development velocity.
The OWASP API Security Top 10 (2023): What Scanners Miss
The OWASP API Security Top 10 2023 defines the most critical API risks. Traditional vulnerability scanners address only a fraction of them:
-
API1:2023 Broken Object Level Authorization (BOLA) — Attackers manipulate object IDs in API calls to access other users’ data. This is the single most exploited API vulnerability and requires context-aware testing to detect because the HTTP response codes look identical to legitimate requests.
-
API2:2023 Broken Authentication — Weak token validation, missing rate limits on credential endpoints, and flawed JWT implementations. Testing must cover token expiration, refresh token rotation, and OAuth/OIDC misconfigurations.
-
API3:2023 Broken Object Property Level Authorization — Combines mass assignment and excessive data exposure. APIs that return full database objects instead of filtered views leak sensitive fields. Scanners must compare response schemas against declared OpenAPI specifications to detect over-exposure.
-
API4:2023 Unrestricted Resource Consumption — Missing rate limiting, unbounded pagination, and expensive query execution. GraphQL APIs are particularly vulnerable here due to nested query complexity.
-
API5:2023 Broken Function Level Authorization — Horizontal and vertical privilege escalation through administrative endpoints exposed without proper role checks.
-
API6:2023 Unrestricted Access to Sensitive Business Flows — Automated abuse of business logic (credential stuffing, inventory hoarding, scraping) that cannot be detected by signature-based scanners.
-
API7:2023 Server-Side Request Forgery (SSRF) — APIs that fetch remote resources can be tricked into accessing internal services. Cloud metadata endpoints (169.254.169.254) are a common target.
-
API8:2023 Security Misconfiguration — Permissive CORS, verbose error messages, missing TLS, and default credentials.
-
API9:2023 Improper Inventory Management — Shadow APIs, deprecated endpoints still accessible, and undocumented versions running in production.
-
API10:2023 Unsafe Consumption of APIs — Trusting third-party API responses without validation, enabling supply chain attacks through API dependencies.
API Gateway Security: Necessary but Not Sufficient
API gateways (Kong, Apigee, AWS API Gateway) provide a first layer of defense — authentication enforcement, rate limiting, request validation, and TLS termination. However, gateways operate at the perimeter and cannot detect:
- Authorization logic flaws that exist within your application code (BOLA, BFLA)
- Business logic abuse that uses valid credentials and well-formed requests
- Schema drift where the actual API behavior diverges from the gateway’s configured policies
- Internal API vulnerabilities between microservices that bypass the gateway entirely
A CTEM approach to API security layers continuous testing behind the gateway, validating that application-level controls actually work as intended.
GraphQL Security Considerations
GraphQL introduces unique security challenges that REST-focused scanners miss entirely:
- Query depth and complexity attacks — Deeply nested queries can exhaust server resources. Without depth limiting and query cost analysis, a single malicious query can cause denial of service.
- Introspection exposure — Production GraphQL endpoints that expose their full schema via introspection give attackers a complete map of your data model and available operations.
- Batching attacks — GraphQL’s ability to batch multiple operations in a single request can bypass rate limiting that operates at the HTTP request level.
- Field-level authorization gaps — Fine-grained access control must be enforced at the resolver level, not at the query level. Testing must verify that each field respects authorization rules independently.
A CTEM Approach to API Security
Applying CTEM’s five phases to API security specifically:
Scoping: Inventory every API — public, partner, internal, and third-party. Use traffic analysis and code scanning to discover undocumented endpoints. Catalog each API by data sensitivity and business criticality.
Discovery: Parse OpenAPI/Swagger specifications, analyze API gateway configurations, and monitor network traffic to build a complete API map. Detect schema drift by comparing documented specifications against actual runtime behavior.
Prioritization: Rank API vulnerabilities by exploitability, data sensitivity, and exposure. A BOLA vulnerability on a public API handling payment data ranks higher than a missing rate limit on an internal monitoring endpoint.
Validation: Use authenticated API scanning with multiple user roles to verify authorization controls. Automated BAS sequences test common API attack chains — privilege escalation, data exfiltration, and injection attacks — against your actual production defenses.
Mobilization: Route validated API findings to the development team that owns the service, with remediation guidance specific to their framework (Express, FastAPI, Spring Boot). Integrate with CI/CD pipelines to block deployments that introduce new API vulnerabilities.
Continuous API Security Testing in Practice
Effective API security testing must be:
- Schema-aware — Using OpenAPI, Swagger, or GraphQL introspection to generate intelligent test cases
- Authentication-aware — Testing with valid tokens across multiple roles to detect authorization flaws
- Event-driven — Triggered by deployments, API specification changes, and new endpoint discovery
- Non-disruptive — Safe to run against production environments without causing data corruption or service degradation
Download the full whitepaper or try VirtueThreatX’s API security scanning with a free trial.