usestrix/strix

api-security-testing

Security-test a REST, GraphQL, or gRPC API with Strix — autonomous agents that enumerate endpoints from an OpenAPI/GraphQL schema (or by crawling), then actually exploit the API-specific vulnerability classes in the OWASP API Security Top 10 (2023) — broken…

Quelltext ansehen
Originales Skill-Dokument

Aus dem Quell-Repository gerendert; Überschriften, Beispiele, Code, Tabellen, Links und Bilder bleiben erhalten.

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. For a run with no Docker and no LLM key, the same binary drives the managed platform: strix cloud login, then strix cloud scans start ... (details in managed-pentesting-with-strix).

1. Gather what the agents need

APIs are near-impossible to test blind, so collect first:

InputWhy it matters
Schema — OpenAPI/Swagger file, Postman collection, GraphQL endpoint (introspection), or a gRPC .protoTurns 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 tenantsBOLA/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 tokenRequired to prove broken function-level authorization (API5:2023 — a user calling admin-only routes).
Example object IDsLets agents test ID tampering immediately instead of hunting for valid identifiers.
Out-of-scope routesPayments, mass notification, destructive admin endpoints.
Rate limits / WAF in front of the APIAvoids agents burning budget on throttled requests; mention them so testing adapts.

Ask the user for anything missing — do not fabricate tokens or scan an API they do not own.

2. Run the scan

Pass the spec as a target, not as prose in the instruction — Strix parses OpenAPI/Swagger (.json/.yaml) and Postman collection exports directly, so the agents start from the real endpoint list:

bash
strix -n -t ./openapi.yaml -t https://api.staging.example.com --max-budget 20 \
  --instruction "Tenant A token: <tokenA> (org 1111, user id 11, order id 501).
Tenant B token: <tokenB> (org 2222, user id 22).
Admin token: <tokenAdmin>.
Focus: BOLA across orgs (API1), function-level authz on /admin/* (API5), object property level authz on PATCH /users/{id} — both mass assignment and over-exposed fields in list responses (API3), unrestricted resource consumption (API4).
Out of scope: POST /billing/*, POST /notifications/broadcast."
  • Postman instead of OpenAPI: a collection export works as a target (-t ./collection.postman_collection.json), or pull one live with -t postman://<collection-uuid> (optionally "postman://<collection-uuid>?env=<environment-uuid>"), which needs POSTMAN_API_KEY in the environment.
  • Many services at once: put one target per line in a file and pass --target-list ./targets.txt, repeatable and combinable with -t.
  • Add the backend source for depth: -t ./services/api -t https://api.staging.example.com. With code access the agents can reason about authorization checks and object ownership rather than inferring them from responses.
  • gRPC: target the endpoint and pass the definition as a workspace file, -t https://grpc.staging.example.com --workspace-file ./service.proto. Only .json, .yaml, and .yml specs are recognized as targets, so -t ./service.proto fails with "Path exists but is not a directory".
  • GraphQL: point at the GraphQL endpoint and say whether introspection is enabled; call out that you want batching/aliasing abuse, depth/complexity limits, and per-field authorization tested.
  • Internal/private APIs unreachable from your machine: use the managed platform's network connector — see managed-pentesting-with-strix.
  • Use --instruction-file when the credential/context block gets long, and keep tokens out of shell history and out of committed files.
  • Supporting files the agents should read but not test, such as an endpoint wordlist or handwritten notes about the tenancy model: pass --workspace-file ./notes.md. The file lands read-only in /workspace. Add :DEST to choose the path, for example --workspace-file ./wordlist.txt:lists/wordlist.txt.

3. Verify findings

strix_runs/<run>/penetration_test_report.md first, then vulnerabilities/*.md — each contains the exact request that proved the issue. Replay it (for example, with curl) before reporting; for authorization findings, confirm the response really contains the other tenant's data rather than an empty 200.

findings.sarif uploads to GitHub code scanning; vulnerabilities.json is the structured index for ticketing.

4. Fix, re-test, and keep it tested

Remediate with fix-security-vulnerabilities-with-strix (fix the authorization check, not the single endpoint), then re-run against the same target to prove the exploit is dead. Wire it into pull-request CI with ci-security-scanning-with-strix so new endpoints get tested as they ship.

aus demselben Repository

Weitere Skills

Alle Skills
usestrix
Community

application-security-testing

Application security testing (AppSec) across a whole product with Strix — decide which asset needs which test (source code, running web app, API, CI pipeline), run it, and turn the results into a ranked remediation plan. Autonomous agents exploit and prove each issue instead of emitting static-analysis alerts, so the plan is ordered by what is actually reachable. Use when the user asks for an application security review or audit, an appsec assessment, vulnerability scanning across their stack, a security review before a launch or a customer security questionnaire, or does not yet know which kind of security test they need.

Installationen
9
GitHub Stars
61.137
Aktualisiert
7. Sept.
usestrix
Community

ci-security-scanning-with-strix

Add security scanning to CI/CD with Strix — GitHub Actions, GitLab CI, or any pipeline — so every pull request gets a diff-scoped AI pentest that blocks vulnerable code before it merges, with results as PR comments and SARIF uploaded to code scanning. Covers both the self-hosted open-source CLI (runs in your runner) and the managed app.strix.ai platform (GitHub/GitLab app or API, no runner infra). Use when the user asks to add security scanning, SAST/DAST, pentesting, vulnerability checks, or automated security review to their CI pipeline, pre-merge gate, or PR workflow.

Installationen
9
GitHub Stars
61.137
Aktualisiert
7. Sept.
usestrix
Community

managed-pentesting-with-strix

Run a managed pentest of a web app, API, repository, or local workspace on the app.strix.ai platform with the strix cloud CLI or REST API — no local Docker or LLM key needed. Safely review and upload local source, register assets, launch and poll scans, triage vulnerabilities, export SARIF, download compliance reports, start PR reviews, buy credits, and set up schedules or webhooks. Use for managed, continuous, scheduled, team-tracked, or sandboxed-agent security testing.

Installationen
9
GitHub Stars
61.137
Aktualisiert
7. Sept.
usestrix
Community

find-security-vulnerabilities-in-code

Find security vulnerabilities in a codebase or repository with Strix — a white-box AI security review that reads your source, reasons about the actual data flow and authorization model, then exploits what it finds in a live sandbox so every reported issue has a working proof-of-concept instead of a noisy static-analysis alert. Covers injection, XSS, SSRF, broken access control and IDOR, insecure deserialization, secrets in code, unsafe dependencies, and business-logic flaws. Use when the user asks to security-scan, security-review, or audit their code, repo, or pull request for vulnerabilities.

Installationen
9
GitHub Stars
61.137
Aktualisiert
7. Sept.