conducting-api-security-testing

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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**:
1. Import Swagger spec into Postman, generating 87 endpoint collections across 12 controllers
2. Discover BOLA on `/api/v1/accounts/{accountId}/transactions` allowing any authenticated user to view any account's transaction history
3. Find mass assignment on the user update endpoint where adding `"dailyTransferLimit": 999999` bypasses the configured transfer limit
4. Identify that the fund transfer endpoint lacks rate limiting, allowing unlimited transfer attempts without throttling
5. Discover that JWT tokens have a 30-day expiration with no refresh token rotation, enabling long-lived session hijacking
6. Find that the admin endpoint `/api/v1/admin/users` is accessible with a standard user token (BFLA)

From 2003gdb/My-Claude-Workflows, Apache-2.0.

More from 2003gdb/My-Claude-Workflows