api-security-testing
Installation
SKILL.md
Security-test an API
APIs fail differently from web UIs: there is no rendered surface to crawl, the interesting bugs are authorization-shaped rather than injection-shaped, and the same endpoint behaves differently per token. This workflow targets those specifics with Strix's autonomous agents, using the current OWASP API Security Top 10 (2023) as the coverage checklist. For the web-app equivalent, the current edition is the OWASP Top 10:2025 — see owasp-top-10-testing.
Install, LLM setup, full CLI flags, and the managed-cloud path are in the penetration-testing-with-strix skill. Read it if strix --version fails or the target is not an API.
1. Gather what the agents need
APIs are near-impossible to test blind, so collect first:
| Input | Why it matters |
|---|---|
Schema — OpenAPI/Swagger file, Postman collection, GraphQL endpoint (introspection), or a gRPC .proto |
Turns guesswork into full endpoint enumeration. Biggest single win in coverage. An OpenAPI/Swagger or Postman spec (.json/.yaml/.yml) is a target Strix takes directly; a .proto is not, so pass it with --workspace-file. |
| Two sets of credentials/tokens, ideally in different tenants | BOLA/IDOR — API1:2023, still the #1 API risk — can only be proven by accessing tenant A's objects with tenant B's token. |
| A low-privilege and a high-privilege token | Required to prove broken function-level authorization (API5:2023 — a user calling admin-only routes). |
| Example object IDs | Lets agents test ID tampering immediately instead of hunting for valid identifiers. |
| Out-of-scope routes | Payments, mass notification, destructive admin endpoints. |
| Rate limits / WAF in front of the API | Avoids agents burning budget on throttled requests; mention them so testing adapts. |