# Web API Pentesting

> 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.

- Skill: `abelrguezr/web-api-pentesting` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/web-api-pentesting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/web-api-pentesting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/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:**
```bash
# 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:**
```bash
# 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:**
```bash
# 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:**
```bash
# 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:**
```bash
# 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:**
```bash
# 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:**
```xml
<!-- 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:**
```bash
# 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:**
```bash
# 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