Test API Security Across 10 Attack Phases

API Security is an authorization-gated skill for a structured discovery-to-report assessment of REST, GraphQL, WebSocket and SOAP APIs. It carries the standard authorized-use banner and mandatory confirmation gate: before probing, exploiting or extracting data from a target, the user must state the exact target, confirm written authorization and scope, see the exact commands and expected effect, and give explicit confirmation.

It covers REST API testing (OpenAPI/Swagger-driven or blind), GraphQL security auditing (introspection, batch queries, alias overloading), WebSocket testing, JWT/OAuth 2.0 authentication testing, BOLA/IDOR/BFLA authorization-flaw detection, and API rate-limit bypass and DoS testing, across a ten-phase flow.

Phase 1 discovers the API surface: crawling with a headless-browser tool (Vespasian) to auto-generate an OpenAPI 3.0 or GraphQL SDL spec, extracting endpoints from robots.txt and JS files, brute-forcing undocumented paths, and checking common spec paths (/swagger.json, /graphql), with a three-tier GraphQL introspection fallback for WAF evasion. Phase 2 tests authentication: JWT attacks (alg:none, RS256-to-HS256 key confusion, weak HMAC brute-forcing, claim tampering, kid path injection) and OAuth 2.0 attacks (redirect_uri manipulation, missing-state CSRF, token leakage via Referer, missing PKCE), plus GraphQL-specific auth bypass via GET-based mutations or batched queries. Phase 3 tests authorization: BOLA via sequential ID/UUID/username enumeration with Burp Autorize dual-session comparison, and BFLA via privilege-escalated API calls, HTTP method switching, API-version downgrade, or injecting an admin ID into a batch operation. Phase 4 is GraphQL-specific: introspection information exposure, alias-overload and batch-query DoS, field-repetition and directive-overload DoS, deep-nesting recursive introspection, error-message field-suggestion leakage, and exposed GraphiQL/Playground consoles. Phase 5 tests REST input validation: HTTP method switching, Content-Type tampering, NoSQL injection, SSRF via webhook/avatar/import URL parameters, XXE, parameter pollution, and mass assignment. Phase 6 tests business logic via version diffing (comparing v1 vs v2 for status-code changes, removed fields or latency regressions), multi-role permission-matrix testing, coupon/points/price manipulation, and race conditions. Phase 7 tests WebSocket endpoints for message injection, prototype pollution, oversized-message handling, type confusion and cross-site WebSocket hijacking. Phase 8 tests rate limits and DoS: bypass via X-Forwarded-For/X-Real-IP headers, path-casing variants, Slowloris, deeply nested GraphQL batch queries, and IP-rotation through a proxy pool. Phase 9 checks data exposure: comparing API response fields against the UI's actual display, pagination-limit enumeration, error-message leakage of stack traces or internal paths, and GraphQL nested-traversal access to unauthorized data. Phase 10 integrates into CI/CD: automatically re-running tests on spec changes, blocking builds past a severity threshold, and persisting findings as regression tests. Before claiming completion the run must have executed every workflow step rather than only reading it, and produced reproducible evidence such as commands, scripts, screenshots or reports.

Use it when an authorized assessment covers API endpoints and needs a structured discovery-to-report workflow, or when testing API authentication, authorization or rate-limiting behavior within an approved scope. Only run it against APIs you are explicitly authorized to test; some checks are intrusive, so prefer a non-production mirror when one is available.

It works with Vespasian for traffic-to-spec generation; Entropy for LLM-generated attack scenarios across five personas (malicious_insider, bot_swarm, penetration_tester, impatient_consumer, confused_user); Escape DAST for business-logic testing; api.sh as an eight-phase, all-protocol attack pipeline; FireTail for twelve GraphQL-specific tests; jwt_tool for comprehensive JWT testing; and Burp Autorize for dual-session authorization comparison. Vespasian drives traffic-to-spec generation with three commands:

vespasian crawl --url https://target.com --depth 3
vespasian import --file traffic.har
vespasian export --format openapi3 --output api-spec.yaml