Chapter 23 Key Takeaways: API Security Testing
Core Principles
-
APIs are the new perimeter. As organizations adopt API-first architectures, APIs expose business logic directly to the internet. Traditional web application testing that focuses on UI-mediated interactions misses API-specific vulnerabilities.
-
Authorization is the primary weakness in APIs. BOLA/IDOR vulnerabilities consistently rank as the #1 API security risk. Every endpoint that accepts object identifiers must verify that the requesting user is authorized to access the specific object.
-
Different API paradigms require different testing approaches. REST, GraphQL, and gRPC each have unique attack surfaces: REST relies on URL-based resources and HTTP methods; GraphQL provides client-controlled queries with introspection; gRPC uses binary Protocol Buffers with reflection.
API Reconnaissance
-
API discovery is the foundation of API security testing. Test common documentation endpoints (swagger.json, openapi.json), analyze JavaScript bundles, use Kiterunner for route discovery, and check historical data via the Wayback Machine.
-
GraphQL introspection reveals the entire attack surface. A single introspection query exposes every type, field, query, mutation, and subscription. Even when introspection is disabled, field suggestion errors and brute-forcing can reveal schema details.
-
Shadow APIs are a critical risk. Organizations typically know about only 60% of their exposed APIs. Deprecated versions, test endpoints, and internal services that are inadvertently exposed represent high-value targets.
BOLA/IDOR
-
Test BOLA systematically with two accounts. Create two accounts at the same privilege level. Access User A's resources with User B's credentials. Test all HTTP methods — authorization on GET does not guarantee authorization on PUT or DELETE.
-
UUIDs reduce enumerability but do not prevent BOLA. UUIDs can be discovered through listing endpoints, API responses, application features, and error messages. The defense is server-side authorization checks, not identifier obscurity.
Mass Assignment and Data Exposure
-
Mass assignment exploits automatic data binding. When APIs bind all request properties to internal objects, attackers can set privileged fields (role, is_admin, balance) that were never intended to be user-modifiable.
-
APIs frequently return more data than necessary. Review every API response for internal fields (cost, supplier info, API keys, internal IDs). Privacy settings enforced only at the UI layer provide no actual protection — the API is the enforcement point.
Rate Limiting and Business Logic
-
Rate limiting must be tested and bypass-resistant. Test X-Forwarded-For manipulation, API version variation, HTTP method variation, and GraphQL batching as bypass techniques. Rate limiting should count operations, not just HTTP requests.
-
Business logic flaws cannot be found by automated scanners. Race conditions, workflow bypasses, price manipulation, and semantic attacks require understanding of intended business processes and manual testing.
-
GraphQL batching and query complexity create unique DoS vectors. Deeply nested queries can cause exponential database operations. Batch operations can bypass per-request rate limiting. Implement query depth limits, complexity analysis, and per-operation rate limiting.
API Authentication
-
Test every endpoint for authentication bypass. Remove auth headers, use empty tokens, expired tokens, tokens from different environments, and tokens from different roles. The Optus breach demonstrated that a single unauthenticated endpoint can expose an entire customer database.
-
Token lifecycle management is critical. Verify that tokens expire, are revoked on logout/password change, and cannot be replayed across environments. Test refresh token rotation — old refresh tokens should be invalidated.
OWASP API Security Top 10
- Use the OWASP API Security Top 10 as a comprehensive testing framework. Each of the 10 categories should be tested across all API paradigms and user roles: BOLA, Broken Authentication, Object Property Authorization, Resource Consumption, Function Level Authorization, Business Flow Abuse, SSRF, Misconfiguration, Inventory Management, and Unsafe Consumption.
Practical Application
-
API security testing requires specialized tools. Postman/Insomnia for API interaction, Kiterunner for discovery, Arjun for parameter enumeration, GraphQL Voyager for schema visualization, grpcurl for gRPC testing, and Burp Suite for interception and manipulation.
-
Document API findings with OWASP API category mappings. This provides a standardized framework that development teams can reference for remediation guidance and security teams can use for tracking and trending.
-
Build reusable automation for repetitive tests. BOLA testing, rate limiting assessment, and authentication bypass testing are performed on every engagement. Investing in automation frameworks saves time and improves consistency.
-
Healthcare and financial APIs require additional regulatory context. FHIR APIs must comply with HIPAA requirements for PHI access controls and audit logging. Financial APIs must comply with PCI DSS and relevant banking regulations.
Return to Chapter 23: API Security Testing