Conducting API Security Testing
When to Use
- Testing API endpoints for authorization flaws, injection vulnerabilities, and business logic bypasses
- Assessing the security of microservices architecture where APIs are the primary communication method
- Validating that API gateway protections (rate limiting, authentication, input validation) are properly enforced
- Testing third-party API integrations for data exposure and insecure configurations
- Evaluating GraphQL APIs for introspection disclosure, query complexity attacks, and authorization bypasses
Do not use against APIs without written authorization, for load testing or denial-of-service testing unless explicitly scoped, or for testing production APIs that process real financial transactions without safeguards.
Prerequisites
- API documentation (OpenAPI/Swagger, GraphQL schema, Postman collection) or application access to reverse-engineer the API
- Burp Suite Professional configured to intercept API traffic with JSON/XML content type handling
- Postman or Insomnia for organizing and replaying API requests across different authentication contexts
- Valid API tokens or credentials at multiple privilege levels (unauthenticated, standard user, admin)
- Target API base URL and version information
Workflow
Step 1: API Discovery and Documentation
Map the complete API attack surface:
Step 2: Authentication and Token Testing
Test authentication mechanisms for weaknesses:
- JWT analysis: Decode the JWT and inspect claims (sub, exp, iss, aud, role). Test:
- Algorithm confusion: Change
alg to none and remove the signature
- Key confusion: Change
alg from RS256 to HS256 and sign with the public key
- Weak secret: Brute-force the HMAC secret with
hashcat -m 16500 jwt.txt wordlist.txt
- Token expiration: Verify tokens expire and cannot be used after expiration
- Claim tampering: Modify role, userId, or permission claims and re-sign
- OAuth 2.0 testing: Check for redirect_uri manipulation, authorization code reuse, token leakage in Referer headers, and missing state parameter (CSRF)
- API key security: Test if API keys are validated per-endpoint, if revoked keys are immediately rejected, and if keys in query strings appear in access logs or analytics
Step 3: Authorization Testing (BOLA/BFLA)
Test for Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA):
Step 4: Input Validation and Injection Testing
Test API inputs for injection and validation flaws:
- SQL injection in API parameters: Test all parameters (path, query, body, headers) with SQL injection payloads. JSON APIs are often overlooked:
{"username": "admin' OR 1=1--", "password": "test"}
- NoSQL injection: For MongoDB backends, test with operator injection:
{"username": {"$gt": ""}, "password": {"$gt": ""}}
- SSRF via API: Test any parameter that accepts URLs (webhook URLs, avatar URLs, import endpoints) with internal addresses and cloud metadata endpoints
- GraphQL-specific injection: Test for query depth attacks, alias-based batching for brute force, and field suggestion enumeration
- XXE in XML APIs: Submit XML content with external entity declarations to API endpoints that accept XML
- Rate limiting validation: Send 100+ rapid requests to authentication endpoints, password reset, and OTP verification to test for brute force protection
Step 5: Data Exposure and Response Analysis
Check for excessive data exposure in API responses:
- Verbose responses: Compare the data returned in API responses with what the UI displays. APIs often return more fields than needed (internal IDs, creation timestamps, email addresses of other users, role information).
- Error message analysis: Trigger errors by sending malformed input, invalid tokens, and non-existent resources. Check if error messages reveal stack traces, database queries, internal paths, or technology details.
- Pagination and enumeration: Test if enumeration is possible by iterating through paginated responses (
/api/users?page=1, page=2, etc.) to extract all records
- GraphQL data exposure: Query for fields not intended for the current user's role. Test nested queries that traverse relationships to access unauthorized data.
- Debug endpoints: Check
/api/debug, /api/status, /metrics, /health, /.env, /api/swagger.json for exposed internal information
Key Concepts
| Term | Definition |
|---|
| BOLA | Broken Object Level Authorization (OWASP API #1); failure to verify that the requesting user is authorized to access a specific object, enabling IDOR attacks |
| BFLA | Broken Function Level Authorization (OWASP API #5); failure to restrict administrative or privileged API functions from being accessed by lower-privilege users |
| Mass Assignment | A vulnerability where the API binds client-provided data to internal object properties without filtering, allowing attackers to modify fields they should not have access to |
| GraphQL Introspection | A built-in GraphQL feature that exposes the complete API schema including all types, fields, and relationships; should be disabled in production |
| JWT | JSON Web Token; a self-contained token format used for API authentication containing claims signed with a secret or key pair |
| Rate Limiting | Controls that restrict the number of API requests a client can make within a time window, preventing brute force, enumeration, and abuse |
Tools & Systems
- Burp Suite Professional: HTTP proxy for intercepting, modifying, and replaying API requests with extensions like Autorize for automated authorization testing
- Postman: API development platform used for organizing endpoint collections, scripting tests, and comparing responses across authentication contexts
- GraphQL Voyager: Visual tool for exploring GraphQL schemas obtained through introspection queries
- jwt.io / jwt_tool: Tools for decoding, analyzing, and tampering with JWT tokens to test authentication bypasses
- Nuclei: Template-based scanner with API-specific templates for detecting common misconfigurations and known vulnerabilities
Common Scenarios
Scenario: API Security Assessment for a Fintech Mobile Application
Context: A fintech startup has a mobile banking application with a REST API backend. The API handles account management, fund transfers, bill payments, and transaction history. The tester has Swagger documentation and accounts at user and admin levels.
Approach:
- Import Swagger spec into Postman, generating 87 endpoint collections across 12 controllers
- Discover BOLA on
/api/v1/accounts/{accountId}/transactions allowing any authenticated user to view any account's transaction history
- Find mass assignment on the user update endpoint where adding
"dailyTransferLimit": 999999 bypasses the configured transfer limit
- Identify that the fund transfer endpoint lacks rate limiting, allowing unlimited transfer attempts without throttling
- Discover that JWT tokens have a 30-day expiration with no refresh token rotation, enabling long-lived session hijacking
- Find that the admin endpoint
/api/v1/admin/users is accessible with a standard user token (BFLA)
- Report all findings with CVSS scores and specific API code-level remediation guidance
Pitfalls:
- Testing only the endpoints documented in Swagger and missing undocumented or deprecated API versions
- Not testing the same endpoint with tokens from every privilege level to detect authorization bypasses
- Ignoring response body analysis for excessive data exposure when the UI only shows a subset of returned fields
- Failing to test for mass assignment by only sending fields shown in the documentation
Output Format
## Finding: Broken Object Level Authorization in Transaction History API
**ID**: API-001
**Severity**: Critical (CVSS 9.1)
**Affected Endpoint**: GET /api/v1/accounts/{accountId}/transactions
**OWASP API Category**: API1:2023 - Broken Object Level Authorization
**Description**:
The transaction history endpoint returns all transactions for the specified
account without verifying that the authenticated user owns the account. Any
authenticated user can view the complete transaction history of any account
by substituting the accountId path parameter.
**Proof of Concept**:
1. Authenticate as User A (account ID: ACC-10045)
2. Request: GET /api/v1/accounts/ACC-10046/transactions
Authorization: Bearer <User_A_token>
3. Response: 200 OK with User B's full transaction history
**Impact**:
Any authenticated user can view the complete financial transaction history of
all 45,000 customer accounts, including amounts, dates, recipients, and
transaction descriptions.
**Remediation**:
Implement server-side authorization check that verifies the authenticated user
owns the requested account before returning data:
const account = await Account.findById(accountId);
if (account.userId !== req.user.id) return res.status(403).json({error: "Forbidden"});
