How to use the OWASP Top 10 Testing agent skill

What an agent skill is and what this one makes the agent do

An agent skill is a folder with a SKILL.md file that gives an AI coding agent specific instructions for a task. When a request matches the skill's description, the agent reads those instructions and follows them.

This skill covers the OWASP Top 10:2025, the widely used list of critical web security risk categories. It guides the agent through running Strix autonomous agents against each category, including broken access control with SSRF, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, integrity failures, logging and alerting failures, and mishandling of exceptional conditions. It also covers the OWASP API Security Top 10 (2023).

• Exercises each category against the real application rather than only listing risks.
• Reports only exploits that were proven, each mapped to its category with a proof-of-concept.
• Explains which categories an agent can test from outside and which need source code or infrastructure review.

Install the owasp-top-10-testing skill

Download the ZIP for the skill from this page and unzip it. Put the resulting folder in one of two places: your personal skills folder at ~/.claude/skills/, or a project's .claude/skills/ folder if you want the skill only for that project.

In the Claude apps, you can instead upload the ZIP under Settings → Capabilities → Skills.

The skill also depends on Strix itself. The skill points to the penetration-testing-with-strix skill for installation and LLM setup. Local runs need Docker and an LLM API key, or you can use the managed Strix cloud platform instead.

• Requirement: Strix installed and configured with an LLM API key, or access to the managed Strix cloud platform.
• Requirement: Docker for local runs.
• Requirement: written authorization and test accounts at multiple privilege levels for the target application.
• Optional: source repository access for dependency and source review.

Trigger the skill with natural requests

You do not need special syntax. Ask for what you want in plain language and make the OWASP link explicit. The skill's description matches requests for an OWASP Top 10 assessment, OWASP compliance testing, or a security review mapped to OWASP categories.

If you need an older edition for a compliance checklist, say so. The skill asks which edition to target before it proceeds, because a report labelled with the wrong edition is misleading.

• Run an OWASP Top 10 assessment on our staging app and map every finding to its 2025 category.
• Do OWASP compliance testing on the customer portal and tell me which categories you could not assess.
• Give me a security review of our API mapped to OWASP categories, using the API Security Top 10 (2023).

Run an assessment: an example command

The skill includes an example Strix command for a full run. It gives the agents both the source and a running instance, plus credentials at two privilege levels. Replace the placeholder values with your own targets and accounts.

The --scan-mode deep flag matters here, because walking ten categories systematically is not a quick scan. The --max-budget flag caps the run cost. Without a second account, access control results are incomplete, and the report should say so.

• Use --scan-mode deep for a full category walk.
• Set --max-budget to cap spending on a run.
• Without a second test account, state in the report that cross-user access results are incomplete.
• Need an auditor-facing PDF? Run the scan on the managed platform and pull the technical report.

Know what an agent can and cannot test

Be clear with stakeholders about coverage. An agent can strongly test some categories from outside the application, such as access control, misconfiguration, injection, and authentication. Others are only partly testable, and one is not testable from outside at all.

A09 Security Logging and Alerting Failures requires reviewing the logging and alerting pipeline, so the report should state it as not assessed rather than passed. Categories A03, A04, A06, A08 and A10 are partial and need source or infrastructure review for full coverage.

• Strong: A01 (including SSRF), A02, A05, A07.
• Partial: A03, A04, A06, A08, A10.
• Not testable from outside: A09.
• For APIs: API1 BOLA, API3 Broken Object Property Level Authorization, and API5 broken function-level authorization.

Read the results and write an honest report

Results are in the strix_runs/<run>/ folder. Group the vulnerabilities/*.md files by category. For each category, state what was attempted, what was proven, and what could not be assessed.

A zero exit code means nothing exploitable was proven in what was analyzed. It does not mean the application is secure. Check the run.json status and cost against your budget, because a run stopped by the budget cap is not a completed assessment. Verify each proof-of-concept yourself before it goes to the user.

• Label the report with the OWASP edition used.
• Report per category: attempted, proven, not assessed.
• Confirm run.json shows a completed run before reporting results.

Fix findings and re-test

After you have confirmed findings, use the fix-security-vulnerabilities-with-strix skill to remediate them. Re-run the assessment to confirm each exploit is closed.

For ongoing coverage as the application changes, use the ci-security-scanning-with-strix skill to gate pull requests.