/conducting-api-security-testing

name: conducting-api-security-testing
description: 'Conducts security testing of REST, GraphQL, and gRPC APIs to identify vulnerabilities in authentication, authorization,
  rate limiting, input validation, and business logic. The tester uses the OWASP API Security Top 10 as the testing framework,
  combining Burp Suite interception with Postman collections and custom scripts to test endpoint security at every privilege
  level. Activates for requests involving API security testing, REST API pentest, GraphQL security assessment, or API vulnerability
  testing.

  '
domain: cybersecurity
subdomain: penetration-testing
tags:
- API-security
- OWASP-API-Top10
- REST
- GraphQL
- authorization-testing
version: 1.0.0
author: mahipal
license: Apache-2.0
nist_csf:
- ID.RA-01
- ID.RA-06
- GV.OV-02
- DE.AE-07

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:

  {"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:

  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 authenticatio