From a548502494e271da2c91bfd1b062f569e58aef04 Mon Sep 17 00:00:00 2001 From: Alex Schapiro Date: Fri, 14 Aug 2026 15:12:04 +0000 Subject: [PATCH] docs(skills): use current OWASP editions (Top 10:2025, API Top 10 2023) --- skills/api-security-testing/SKILL.md | 10 ++++---- skills/owasp-top-10-testing/SKILL.md | 38 +++++++++++++++------------- 2 files changed, 25 insertions(+), 23 deletions(-) diff --git a/skills/api-security-testing/SKILL.md b/skills/api-security-testing/SKILL.md index ebfaba98..2d60673d 100644 --- a/skills/api-security-testing/SKILL.md +++ b/skills/api-security-testing/SKILL.md @@ -1,6 +1,6 @@ --- name: api-security-testing -description: 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 the OWASP API Security Top 10 covers — broken object-level authorization (BOLA/IDOR), broken function-level authorization, excessive data exposure, mass assignment, injection, SSRF, and auth/token flaws. Every finding comes with a working proof-of-concept request. Use when the user asks to pentest, security-test, audit, or find vulnerabilities in an API, endpoint, or backend service. +description: 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 object-level authorization (BOLA/IDOR), broken object property level authorization (excessive data exposure and mass assignment), broken function-level authorization, unrestricted resource consumption, SSRF, injection, and auth/token flaws. Every finding comes with a working proof-of-concept request. Use when the user asks to pentest, security-test, audit, or find vulnerabilities in an API, endpoint, or backend service. license: Apache-2.0 metadata: author: usestrix @@ -9,7 +9,7 @@ metadata: # Security-test an API -APIs fail differently from web UIs: there's 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. +APIs fail differently from web UIs: there's 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)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) 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 isn't an API. @@ -20,8 +20,8 @@ APIs are near-impossible to test blind, so collect first: | Input | Why it matters | |---|---| | **Schema** — OpenAPI/Swagger URL or file, GraphQL endpoint (introspection), or `.proto` | Turns guesswork into full endpoint enumeration. Biggest single win in coverage. | -| **Two sets of credentials/tokens**, ideally in different tenants | BOLA/IDOR — the #1 API vulnerability class — 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 (a `user` calling admin-only routes). | +| **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. | @@ -36,7 +36,7 @@ strix -n -t https://api.staging.example.com --max-budget 20 \ Tenant A token: (org 1111, user id 11, order id 501). Tenant B token: (org 2222, user id 22). Admin token: . -Focus: BOLA/IDOR across orgs, function-level authz on /admin/*, mass assignment on PATCH /users/{id}, excessive data exposure in list responses. +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." ``` diff --git a/skills/owasp-top-10-testing/SKILL.md b/skills/owasp-top-10-testing/SKILL.md index 642c2c55..ae57864d 100644 --- a/skills/owasp-top-10-testing/SKILL.md +++ b/skills/owasp-top-10-testing/SKILL.md @@ -1,6 +1,6 @@ --- name: owasp-top-10-testing -description: Test an application against the OWASP Top 10 with Strix — autonomous AI agents that attempt real exploits for each category (broken access control, cryptographic failures, injection, insecure design, misconfiguration, vulnerable components, auth failures, integrity failures, logging gaps, SSRF) and report only what they could actually prove, mapped back to the category with a proof-of-concept. Also covers the OWASP API Security Top 10. Use when the user asks for an OWASP Top 10 assessment, OWASP compliance testing, or a security review mapped to OWASP categories. +description: Test an application against the OWASP Top 10 with Strix — autonomous AI agents that attempt real exploits for each category of the current OWASP Top 10:2025 (broken access control including SSRF, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, integrity failures, logging and alerting failures, mishandling of exceptional conditions) and report only what they could actually prove, mapped back to the category with a proof-of-concept. Also covers the OWASP API Security Top 10 (2023). Use when the user asks for an OWASP Top 10 assessment, OWASP compliance testing, or a security review mapped to OWASP categories. license: Apache-2.0 metadata: author: usestrix @@ -9,7 +9,9 @@ metadata: # Test against the OWASP Top 10 -The OWASP Top 10 is a taxonomy of risk categories, not a test suite — so "OWASP Top 10 testing" means exercising each category against the real application and reporting what's actually exploitable. Strix's agents do the exploitation; this skill covers running it category-by-category and honestly reporting coverage. +The OWASP Top 10 is a taxonomy of risk categories, not a test suite — "OWASP Top 10 testing" means exercising each category against the real application and reporting what's actually exploitable. Strix's agents do the exploitation; this skill covers running it category-by-category and reporting coverage honestly. + +**Use the current edition: [OWASP Top 10:2025](https://owasp.org/Top10/)** (8th installment, superseding 2021). Ask the user before targeting an older edition — some compliance checklists still reference 2021, and a report labelled with the wrong edition is misleading. Key differences from 2021: **SSRF is folded into A01**, **A03 Software Supply Chain Failures** expands the old "Vulnerable and Outdated Components", and **A10 Mishandling of Exceptional Conditions** is new; A02 Security Misconfiguration moved 5→2. Install, LLM setup, and the managed-cloud alternative: **penetration-testing-with-strix**. @@ -17,20 +19,20 @@ Install, LLM setup, and the managed-cloud alternative: **penetration-testing-wit Be straight with the user about this — claiming a clean sweep of all ten is misleading. -| Category (2021) | Coverage | +| Category (2025) | Coverage | |---|---| -| A01 Broken Access Control | **Strong** — needs two accounts (and a privileged one) to prove cross-user/tenant and privilege-escalation access. | -| A02 Cryptographic Failures | **Partial** — transport config, weak/absent encryption of data in transit, tokens and secrets exposed in responses; at-rest crypto needs source or infra review. | -| A03 Injection | **Strong** — SQL/NoSQL/command/template injection and XSS, exploit-validated. | -| A04 Insecure Design | **Partial** — business-logic abuse (price/quantity tampering, workflow skipping, race conditions) is found where reachable; design intent still needs human review. | -| A05 Security Misconfiguration | **Strong** — debug endpoints, verbose errors, permissive CORS, missing hardening, default credentials, exposed admin surfaces. | -| A06 Vulnerable & Outdated Components | **Partial** — version fingerprinting plus dependency review when source is supplied; use a dedicated SCA tool for exhaustive dependency inventory. | -| A07 Identification & Auth Failures | **Strong** — auth bypass, weak session/token handling, password-reset and MFA flaws. | -| A08 Software & Data Integrity Failures | **Partial** — insecure deserialization and unsigned-update paths where reachable; CI/CD supply-chain integrity is out of scope for a runtime scan. | -| A09 Logging & Monitoring Failures | **Not testable from outside** — requires reviewing the logging/alerting pipeline; state this rather than reporting it as passed. | -| A10 SSRF | **Strong** — exploit-validated, including blind SSRF via out-of-band callbacks. | +| A01 Broken Access Control (incl. SSRF) | **Strong** — cross-user/tenant access, privilege escalation, IDOR, and SSRF (including blind, via out-of-band callbacks) are all exploit-validated. Needs two accounts plus a privileged one to prove the authorization half. | +| A02 Security Misconfiguration | **Strong** — debug endpoints, verbose errors, permissive CORS, missing hardening, default credentials, exposed admin surfaces. | +| A03 Software Supply Chain Failures | **Partial** — version fingerprinting, and vulnerable/outdated dependency review when source is supplied. Build-system and distribution-infrastructure compromise (the broader half of this category) is out of scope for a runtime scan — pair with SCA plus build-provenance controls. | +| A04 Cryptographic Failures | **Partial** — transport config, unencrypted data in transit, secrets and tokens leaked in responses. At-rest crypto and key management need source or infra review. | +| A05 Injection | **Strong** — SQL/NoSQL/command/template injection and XSS, exploit-validated. | +| A06 Insecure Design | **Partial** — business-logic abuse (price/quantity tampering, workflow skipping, race conditions) is found where reachable; design intent still needs human review and threat modelling. | +| A07 Authentication Failures | **Strong** — auth bypass, weak session/token handling, password-reset and MFA flaws. | +| A08 Software or Data Integrity Failures | **Partial** — insecure deserialization and unsigned-update paths where reachable; CI/CD trust boundaries are not runtime-testable. | +| A09 Security Logging & Alerting Failures | **Not testable from outside** — requires reviewing the logging and alerting pipeline. State this rather than reporting it as passed. | +| A10 Mishandling of Exceptional Conditions | **Partial** — agents actively probe error handling and fail-open behavior (malformed input, forced errors, race and timeout conditions) and report what leaks or bypasses a control; exhaustive coverage of internal error paths needs source review. | -For APIs, run the same exercise against the **OWASP API Security Top 10** (BOLA, broken function-level authz, mass assignment, excessive data exposure) using the **api-security-testing** skill. +For APIs, run the same exercise against the **OWASP API Security Top 10 (2023)** — API1 BOLA, API3 Broken Object Property Level Authorization (2019's excessive data exposure + mass assignment merged), API5 broken function-level authorization — using the **api-security-testing** skill. ## Run it @@ -41,19 +43,19 @@ strix -n \ -t https://github.com/org/app \ -t https://staging.example.com \ --scan-mode deep --max-budget 30 \ - --instruction "OWASP Top 10 (2021) assessment. Cover every category systematically and map each finding to its category. + --instruction "OWASP Top 10:2025 assessment. Cover every category systematically and map each finding to its 2025 category id. Accounts: userA@example.com/ (org 1), userB@example.com/ (org 2), admin@example.com/. -Prioritise A01 (cross-org and privilege escalation), A03, A05, A07, A10. +Prioritise A01 (cross-org access, privilege escalation, SSRF), A02, A05, A07, A10. Out of scope: /billing/*, outbound email." ``` - `--scan-mode deep` matters here: systematically walking ten categories is not a quick scan. - Without a second account, A01 results are structurally incomplete — say so in the report rather than leaving it implied. -- Need an auditor-facing PDF mapped to categories? Run it through the managed platform and pull the technical report (**managed-pentesting-with-strix**). +- Need an auditor-facing PDF? Run it through the managed platform and pull the technical report (**managed-pentesting-with-strix**). ## Report honestly -From `strix_runs//`, group `vulnerabilities/*.md` by OWASP category and state, per category: what was attempted, what was proven, and what couldn't be assessed (A09 always, A02/A06/A08 partially). Verify each PoC yourself before it goes in front of the user. +From `strix_runs//`, group `vulnerabilities/*.md` by category and state, per category: what was attempted, what was proven, and what couldn't be assessed (A09 always; A03/A04/A06/A08/A10 partially). Label the report with the edition used. Verify each PoC yourself before it goes in front of the user. A `0` exit code means nothing exploitable was proven **in what was analyzed** — check `run.json` status and cost against `--max-budget`; a budget-capped run is not a completed assessment.