web-app-penetration-testing
- Use it when:
- You want a black-box (or source-assisted) pentest of a running web app or staging site.
- It does:
- Runs Strix agents against the URL with your test credentials and scope, exploiting and proving each finding.
- You get:
- A report and per-finding PoCs, strongest on multi-tenant IDOR and broken access control.
- Needs:
- The Strix CLI or cloud; two test accounts and credentials sharply improve results.
Skill 4 of 8 in the Strix bundle, after find-security-vulnerabilities-in-code and before api-security-testing.
Install and CLI setup live in the penetration-testing-with-strix skill. Runs the Strix CLI (Docker + LLM key) or the cloud (account); only test apps you own or are authorized to test.
TL;DR
The web-app-specific Strix workflow. It first pins down authorization and scope (the target is yours, prefer staging since agents send real payloads and change data, out-of-scope paths, and test credentials), because most real bugs live behind login and cross-account access can only be proven with two accounts. Then it runs a headless scan against the URL, passing credentials and focus areas by instruction, optionally adding the repo as a second target for white-box depth, and can reach a localhost dev server from the sandbox. It reads the report and per-finding PoCs, re-running each exploit to confirm it, and warns that a budget-capped run exiting clean is not full coverage. Setup and all flags live in the penetration-testing skill; hand findings to the fix skill and gate PRs with the CI skill.
Summarizes the skill at 0601550.
npx skills add https://github.com/usestrix/strix --skill web-app-penetration-testing skills.sh pageSource on GitHubAll skills from usestrix/strix
- Total Downloads
- 16,100 on skills.sh, Nov 9, 2026
- Repo stars
- 74,490 usestrix/strix
- First seen
- Aug 20, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 1,099 |
| Sep 28 | 1,074 |
| Oct 5 | 1,144 |
| Oct 12 | 1,197 |
| Oct 19 | 1,663 |
| Oct 26 | 1,703 |
| Nov 2 | 1,736 |
| Nov 9 | 1,510 |
| Category |
Compliance, guardrails, skill vetting and browser fingerprinting. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
Operates a CLI, API, app or bundled script to get something done. |
| Effect |
Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service. |
| Needs |
A specific command-line tool or desktop app must be installed, such as gh, agent-browser, LibreOffice, Obsidian or a vendor CLI. An account, API key or paid plan with an outside service. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics | |
| Stack |
SKILL.md
From usestrix/strix at 0601550. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: web-app-penetration-testing
description: Pentest a web app or website end to end — black-box testing of a live URL, staging environment, or local dev server that finds and exploits real vulnerabilities (auth bypass, broken access control, IDOR, injection, XSS, SSRF, business logic) and proves each one with a working proof-of-concept instead of a signature match. Runs with Strix, either the self-hosted open-source CLI or the managed app.strix.ai cloud. Use when the user asks to pentest, hack, security-test, or audit their web app, website, web application, or staging site.
license: Apache-2.0
metadata:
author: usestrix
homepage: https://docs.strix.aiPentest a web application
Black-box (and optionally source-assisted) penetration testing of a running web app with Strix's autonomous agents. Every reported finding is validated with a working exploit, so there are no signature-based false positives to triage.
Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the penetration-testing-with-strix skill — read it if the target is not a running web app, or if strix --version fails. 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). This skill is the web-app-specific workflow.
1. Confirm authorization and scope
Before running anything, establish:
- The target is the user's (or they are explicitly authorized to test it). Never pentest a third-party site on a hunch.
- Which environment. Prefer staging over production; agents send real exploit payloads and will create/modify data.
- Out-of-scope paths — payment flows, mass-email endpoints, admin destructive actions, third-party SSO providers.
- Credentials. Most real vulnerabilities live behind login. Without a test account, the agents only ever see the marketing surface.
Ask for anything missing rather than guessing.
2. Run the scan
strix -n -t https://staging.example.com --max-budget 20 \
--instruction "Test account: qa@example.com / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."
Notes that matter for web apps specifically:
- Give it credentials via
--instruction(or--instruction-filefor anything long), including how to log in if the flow is unusual (magic link, SSO, MFA-exempt test user). - Two accounts beat one. Multi-tenant IDOR and broken-access-control bugs — consistently the highest-impact class in web apps — can only be proven when the agent can attempt cross-account access.
- Add the repo for white-box depth when you have the source:
-t https://github.com/org/app -t https://staging.example.com(or a local path). Source access materially improves coverage of business-logic and authorization flaws. - Localhost works. Point at
http://host.docker.internal:3000(Docker Desktop) so the sandbox can reach a dev server on the host. --scan-mode quickfor a fast dev-loop pass,standard(~30 min) for a normal review,deepfor pre-release assurance. Always set--max-budget.
For a hosted run with no Docker/LLM key, or when the user wants a shareable dashboard and an auditor-ready PDF, use the cloud path in managed-pentesting-with-strix instead — same engine, same findings.
3. Review results
Read strix_runs/<run>/penetration_test_report.md first, then per-finding files in vulnerabilities/. Each contains the PoC — re-run it yourself to confirm before reporting to the user.
Exit codes: 0 no validated vulns in what was analyzed, 2 vulnerabilities found, 1 fatal error. A 0 is not proof of full coverage — if the budget or turn cap was hit the scan wraps up early, so check run.json status and cost against --max-budget before calling the app clean.
4. Fix and verify
Hand findings to the fix-security-vulnerabilities-with-strix skill: patch the root cause, then re-run Strix against the same target to prove the exploit no longer works. Re-testing is the only reliable confirmation a fix landed.
To keep the app tested on every change rather than once, wire Strix into CI with ci-security-scanning-with-strix.