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:

Import API documentation: Load OpenAPI/Swagger specs into Postman or Burp Suite to catalog all endpoints, methods, parameters, and authentication requirements
Reverse-engineer undocumented APIs: Proxy the mobile app or web frontend through Burp Suite and exercise all features to capture API calls. Export the Burp sitemap as the baseline endpoint inventory.
GraphQL introspection: Send an introspection query to discover the full schema:
json
```
{"query": "{__schema{types{name,fields{name,args{name,type{name}}}}}}"}
```
Endpoint enumeration: Fuzz for hidden API versions (
```
/api/v1/
```
,
```
/api/v2/
```
,
```
/api/internal/
```
), debug endpoints (
```
/api/debug
```
,
```
/api/health
```
,
```
/api/metrics
```
), and administrative endpoints
Document authentication mechanisms: Identify if the API uses API keys, OAuth 2.0 Bearer tokens, JWT, session cookies, or mutual TLS

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):

BOLA (IDOR) testing: For every endpoint that returns user-specific data, replace the object identifier with another user's identifier:
- ```
GET /api/users/123/orders
```
  ->
```
GET /api/users/456/orders
```
- Test with numeric IDs, UUIDs, usernames, and email addresses
- Automate with Burp Autorize extension: configure it with two sessions (attacker and victim) and replay all requests
BFLA testing: Using a low-privilege token, attempt to access administrative endpoints:
- ```
DELETE /api/users/456
```
  (admin-only delete)
- ```
PUT /api/users/456/role
```
  (role modification)
- ```
GET /api/admin/dashboard
```
  (admin panel data)

Mass assignment: Send additional JSON properties not shown in the documentation:

json

PUT /api/users/123
{"name": "Test", "role": "admin", "isVerified": true, "balance": 99999}

HTTP method testing: If GET works on an endpoint, try PUT, PATCH, DELETE, and OPTIONS to discover unprotected methods

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"});

conducting-api-security-testing

NPX Install

Tags

SKILL.md Content