Skills usestrix strix Strix

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
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 Downloads
1.5K
+37% over the 8 weeks to Nov 9
Weekly values
Week toInstalls
Sep 211,099
Sep 281,074
Oct 51,144
Oct 121,197
Oct 191,663
Oct 261,703
Nov 21,736
Nov 91,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.ai

Pentest 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-file for 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 quick for a fast dev-loop pass, standard (~30 min) for a normal review, deep for 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.