Web API Pentesting

Web API Pentesting Skill

A comprehensive methodology for security testing web APIs, covering REST, SOAP, GraphQL, and modern TypeScript stacks like tRPC.

Quick Start

1. Identify API type (REST/JSON, SOAP/XML, GraphQL, tRPC)
2. Map the attack surface (endpoints, parameters, authentication)
3. Test for common vulnerabilities (authorization, injection, misconfigurations)
4. Document findings with proof-of-concept requests

API Type Identification

REST APIs (JSON)

• Look for /api/ paths, JSON responses, Swagger/OpenAPI docs
• Check for swagger.json, openapi.yaml, or /api-docs endpoints
• Use Postman or curl to explore endpoints

SOAP/XML Web Services

• Check for ?wsdl paths (e.g., service.asmx?wsdl)
• Look for XML responses and SOAP envelopes
• Use SOAPUI or Burp Suite's WSDLer extension

GraphQL

• Look for /graphql or /api/graphql endpoints
• Test introspection queries to map schema
• Check for query complexity limits

tRPC (TypeScript Runtime)

• Look for /api/trpc/<router>.<procedure> patterns
• JSON body wrapped as {"input": {...}}
• Common in modern TypeScript/Next.js stacks

Core Testing Methodology

1. Endpoint Discovery

Manual techniques:

• Check documentation (Swagger, Postman collections, README files)
• Review JavaScript bundles for API calls
• Monitor network traffic in browser DevTools
• Check for common patterns: /api/v1/, /api/v2/, /api/admin/

Automated discovery:

# Using kiterunner for endpoint discovery
kr scan https://target.com/api/ -w routes-large.kite -x 20
kr brute https://target.com/api/ -A=raft-large-words -x 20 -d=0

# Using ffuf for path fuzzing
ffuf -u https://target.com/api/FUZZ -w /path/to/wordlist.txt

2. Authentication Testing

Test cases:

• Can you bypass authentication entirely?
• Does removing auth headers still work?
• Can you use another user's token/cookie?
• Test for session fixation and hijacking

Key checks:

• Try requests without authentication
• Test with expired/invalid tokens
• Attempt to use tokens across different user accounts
• Check for proper session invalidation on logout

3. Authorization Testing (AuthN ≠ AuthZ)

Critical distinction: Authentication proves who you are. Authorization determines what you can do.

Broken Object Level Authorization (BOLA) testing:

# 1. Get your own resource
GET /api/users/123  # Your user ID

# 2. Try accessing another user's resource
GET /api/users/124  # Different user ID
GET /api/users/1    # Admin user ID

# 3. Test with negative/zero IDs
GET /api/users/-1
GET /api/users/0

tRPC-specific authorization pitfalls:

• protectedProcedure only checks authentication, NOT authorization
• Look for admin-only procedures accessible to regular users
• Test background job controls, feature flags, tenant-wide operations

Example tRPC exploitation:

# Enumerate background jobs (should be admin-only)
curl -s -X POST 'https://target.com/api/trpc/backgroundMigrations.all' \
  -H 'Content-Type: application/json' \
  -b '<AUTH_COOKIES>' \
  --data '{"input":{}}'

# Trigger privileged action (restart migration)
curl -s -X POST 'https://target.com/api/trpc/backgroundMigrations.retry' \
  -H 'Content-Type: application/json' \
  -b '<AUTH_COOKIES>' \
  --data '{"input":{"name":"critical_migration"}}'

Impact assessment:

• Data corruption via non-idempotent operations
• DoS through worker/DB exhaustion
• Unauthorized data access or modification

4. Parameter Tampering

Test techniques:

• Add unexpected parameters
• Modify parameter values (IDs, flags, limits)
• Change data types (string to number, boolean to string)
• Test parameter pollution (duplicate parameters)

Examples:

# Original request
GET /api/products?id=123

# Tampered requests
GET /api/products?id=123&admin=true
GET /api/products?id=123&price=0
GET /api/products?id=123&limit=10000
GET /api/products?id=123%26id=124  # Parameter pollution

5. HTTP Method Testing

Test all methods on each endpoint:

# Try different methods on the same endpoint
curl -X GET https://target.com/api/users/123
curl -X POST https://target.com/api/users/123
curl -X PUT https://target.com/api/users/123
curl -X DELETE https://target.com/api/users/123
curl -X PATCH https://target.com/api/users/123
curl -X OPTIONS https://target.com/api/users/123

Look for:

• Unexpected method support
• Information disclosure via OPTIONS
• Method-based privilege escalation

6. Content-Type Manipulation

Test different content types:

# JSON to XML
curl -X POST https://target.com/api/data \
  -H 'Content-Type: application/xml' \
  --data '<data><id>123</id></data>'

# Form data to JSON
curl -X POST https://target.com/api/data \
  -H 'Content-Type: application/json' \
  --data '{"id": 123}'

Vulnerabilities to find:

• XML External Entity (XXE) injection
• JSON parsing issues
• Content-Type bypass attacks

7. SOAP/XML Specific Testing

XXE Injection:

<!-- Test for XXE in SOAP requests -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <test>
      <data>
        <![CDATA[<!ENTITY xxe SYSTEM "file:///etc/passwd">&xxe;]]>
      </data>
    </test>
  </soap:Body>
</soap:Envelope>

Check for:

• DTD declarations (often restricted)
• CDATA tag payload insertion
• XML entity expansion attacks

8. CORS Misconfiguration Testing

Test cases:

# Check CORS headers
curl -I -H 'Origin: https://evil.com' https://target.com/api/data

# Test with different origins
curl -I -H 'Origin: https://attacker.com' https://target.com/api/data

# Check for wildcard CORS
# Look for: Access-Control-Allow-Origin: *

Vulnerabilities:

• Access-Control-Allow-Origin: * with credentials
• Reflected origin without validation
• Missing CORS headers on sensitive endpoints

9. Version Testing

Test multiple API versions:

# Check for versioned endpoints
GET /api/v1/users
GET /api/v2/users
GET /api/v3/users

# Test older versions for vulnerabilities
GET /api/v1/admin/users  # May lack newer security controls

Why it matters:

• Older versions often have known vulnerabilities
• Security controls may not be backported
• Deprecated endpoints may be forgotten

Tool Recommendations

Endpoint Discovery

• kiterunner: API endpoint discovery and brute forcing
• ffuf: Fast web fuzzer for path discovery
• Burp Suite: Professional web proxy with API testing features

API Auditing

• sj (BishopFox): Audit exposed Swagger/OpenAPI files
• Cherrybomb: OAS-based API security auditing (Rust)
• Postman: Manual API testing and collection management

Specialized Tools

• SOAPUI: SOAP API testing
• WSDLer: Burp extension for WSDL parsing
• Logger++: Burp extension with API vulnerability filters

Common Vulnerability Patterns

OWASP API Security Top 10

1. Broken Object Level Authorization (BOLA) - Most common
2. Broken Authentication - Session/token issues
3. Broken Object Property Level Authorization - Mass assignment
4. Unrestricted Resource Consumption - Rate limiting bypass
5. Broken Function Level Authorization - Admin functions accessible
6. Unrestricted Access to Sensitive Business Flows - Business logic abuse
7. Server Side Request Forgery (SSRF) - Internal network access
8. Security Misconfiguration - Default configs, verbose errors
9. Improper Inventory Management - Unknown endpoints
10. Unsafe Consumption of APIs - Third-party API risks

Quick Reference Checklist

• Map all API endpoints
• Test authentication bypass
• Test authorization (BOLA, BFLA)
• Test parameter tampering
• Test HTTP methods
• Test content-type manipulation
• Test CORS configuration
• Test for XXE (SOAP/XML)
• Test multiple API versions
• Review error messages for information disclosure
• Test rate limiting
• Check for sensitive data in responses

Practice Resources

• VAmPI: Deliberately vulnerable API for practice
• OWASP API Security Top 10: Essential reading
• API Security Checklist: Comprehensive security guide
• Logger++ Filters: Burp filters for API hunting

Reporting Findings

For each vulnerability, document:

1. Endpoint: Full URL and HTTP method
2. Vulnerability type: Specific classification
3. Steps to reproduce: Exact requests needed
4. Impact: What an attacker could do
5. Remediation: How to fix it
6. Proof of concept: Request/response examples

Example report entry:

Vulnerability: Broken Object Level Authorization
Endpoint: GET /api/users/{id}
Severity: High
Description: Users can access other users' data by modifying the ID parameter
Steps:
1. Authenticate as user A (ID: 123)
2. Request /api/users/123 (returns own data)
3. Request /api/users/124 (returns user B's data - unauthorized)
Impact: Full data exposure across all users
Remediation: Add authorization check to verify user owns requested resource

Next Steps

After initial testing:

1. Prioritize findings by severity and exploitability
2. Validate false positives with additional testing
3. Document remediation guidance for developers
4. Re-test after fixes are applied
5. Consider automated scanning for ongoing monitoring