web-api-pentesting

name

web-api-pentesting

description

How to perform comprehensive security testing on web APIs including REST, SOAP, GraphQL, and tRPC endpoints. Use this skill whenever the user needs to audit API security, test for authorization flaws, discover hidden endpoints, or assess API vulnerabilities. Trigger this skill for any API security assessment, penetration testing of web services, or when investigating potential API-based attacks like BOLA, XXE, or parameter tampering.

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