APIs are the connective tissue of modern software architecture — they power mobile applications, enable third-party integrations, underpin microservices, and expose business functionality to external partners. They are also the primary attack surface in contemporary web application breaches. The 2019 Capital One breach exploited an SSRF vulnerability in a metadata service API. The 2022 Optus breach in Australia exposed the personal information of approximately 9.5 million current and former customers after a coding error left an access control on an internet-facing customer API ineffective (Office of the Australian Information Commissioner; Australian Communications and Media Authority). The pattern repeats because API security requires a different testing mindset than traditional web application security.
OWASP publishes the API Security Top 10 — last updated in 2023 — as a framework for understanding and testing the most impactful API vulnerability classes. This post covers each category with testing methodology and remediation guidance.
OWASP API Security Top 10 (2023)
API1: Broken Object Level Authorization (BOLA / IDOR)
BOLA is the most prevalent and impactful API vulnerability class. It occurs when an API endpoint receives an object identifier (user ID, order ID, account number) in the request and returns the corresponding object without verifying that the requesting user is authorized to access that specific object.
Example: GET /api/v1/invoices/10293 returns invoice 10293 for user A. User B can retrieve the same endpoint by changing the ID to 10292 — accessing user A's invoice data. Testing methodology: authenticate as user A, capture a request referencing an object ID, log in as user B and replay the request with the same object ID. If user B receives user A's data, the endpoint is vulnerable. Automate across ID ranges using Burp Suite Intruder or a custom script.
API2: Broken Authentication
Authentication failures include: weak API key generation (sequential, short, or low-entropy keys), API keys transmitted in URL query strings (logged in proxy/server access logs and browser history), missing token expiration, JWT vulnerabilities (see our dedicated JWT guide), and insecure password reset flows. Test: attempt authentication with expired tokens, replay captured tokens, test password reset flows for account takeover.
API3: Broken Object Property Level Authorization (BOPLA)
Even when object-level authorization is correct, APIs may expose or accept modification of object properties the current user should not access. Mass assignment vulnerabilities fall here: an API that accepts a JSON body with any user-supplied fields may allow privilege escalation by including fields like "isAdmin": true or "role": "superuser". Test: send extra fields in PUT/PATCH requests. Review API responses for unexpectedly returned fields containing sensitive data (PII fields, internal identifiers, password hashes).
API4: Unrestricted Resource Consumption
APIs without rate limiting or resource controls are vulnerable to denial of service, credential stuffing, and enumeration attacks. Test: send requests at high volume without rate limiting being enforced; test large request bodies; test resource-intensive operations (complex searches, bulk exports) without throttling. Confirm whether the API enforces pagination limits, request size limits, and per-endpoint rate limits.
API5: Broken Function Level Authorization
Administrative or privileged API functions exposed to lower-privilege users. Common pattern: a mobile application exposes only user-facing endpoints in its UI, but administrative endpoints exist at the same base path and are accessible to authenticated non-admin users. Test: enumerate all endpoints using Swagger/OpenAPI documentation, JavaScript source analysis, and forced browsing. Attempt to access admin-tier endpoints (path patterns like /admin/, /internal/, /management/) with standard user credentials.
API6: Unrestricted Access to Sensitive Business Flows
Beyond raw rate limiting, some business flows can be abused through automation even at low request rates. Examples: buying out limited inventory using automated cart scripts, bulk-generating referral codes, or mass-extracting data through legitimate API functionality. Test by automating business flows that should be limited by human interaction speed and assessing whether the application detects or limits this.
API7: Server Side Request Forgery (SSRF)
APIs that accept URLs as input and make server-side requests to those URLs are vulnerable to SSRF. An attacker can redirect these requests to internal services (AWS metadata service at 169.254.169.254, internal Kubernetes APIs, internal databases). Test: supply internal IP addresses, cloud metadata endpoint URLs, and localhost references as URL parameters. Test both direct SSRF (response returned to attacker) and blind SSRF (no response, detect via out-of-band DNS callback to Burp Collaborator or interactsh).
API8: Security Misconfiguration
Misconfiguration findings include: CORS misconfiguration (overly permissive Access-Control-Allow-Origin: * on authenticated endpoints), verbose error messages exposing stack traces and internal paths, unnecessary HTTP methods enabled (TRACE, DELETE on read-only endpoints), missing security headers, exposed debug endpoints, and outdated API versions still running in production. Test systematically: check CORS headers, send unexpected HTTP methods, trigger errors and inspect responses, check for debug endpoints (/debug, /actuator, /metrics, /swagger-ui in production).
API9: Improper Inventory Management
Organizations frequently lose track of their API surface: old API versions (v1, v2) left running after v3 launch, internal APIs exposed to external networks, undocumented partner APIs. Old API versions often lack security controls added in newer versions. Test: attempt access to deprecated version paths (/api/v1/ when production is /api/v3/). Use DNS enumeration and certificate transparency to discover API subdomains not in official documentation.
API10: Unsafe Consumption of APIs
Applications that consume third-party APIs without validating responses are vulnerable to supply-chain attacks if the upstream API is compromised. Insufficient validation of third-party API responses can lead to injection attacks, path traversal, or data poisoning in downstream processing. Review code that consumes external APIs for input validation on all returned fields before use.
GraphQL-Specific Security Issues
GraphQL APIs introduce additional attack surface beyond REST:
- Introspection in production: GraphQL introspection queries (
{ __schema { types { name fields { name } } } }) return the complete API schema, exposing all types, fields, and mutations. Disable introspection in production environments. - Deep query / query complexity DoS: GraphQL allows nested queries with no native depth limit. An attacker can craft a deeply nested query that causes exponential database load. Implement query depth limits and complexity analysis.
- Field-level authorization bypass: Authorization may be enforced at the resolver level but not consistently across all fields accessing the same data. Test each field individually for BOLA and BOPLA vulnerabilities.
- Batch query abuse: GraphQL allows multiple operations in a single request. Rate limiting at the HTTP level does not limit the number of operations per request. Implement operation-level rate limiting.
Testing Tools
Burp Suite Professional with the GraphQL Raider extension is the primary tool for API security testing. Postman is useful for functional API testing and building authenticated request collections. Swagger/OpenAPI documentation, when available, provides a complete list of endpoints and parameters to test. Kiterunner (from AssetNote) provides wordlist-based API endpoint discovery superior to traditional directory brute forcing for REST APIs.
Fortress MSSP conducts dedicated API security assessments as part of our penetration testing service line. API assessments cover REST, GraphQL, and gRPC interfaces with full OWASP API Top 10 coverage. Contact us to scope an assessment for your API infrastructure.