authorized-web-pentest git:20260703.247aff5A

Immutable. This exact content never changes and is served at /api/v1/blob/f37cf4b0f1a64dc8.

---
name: authorized-web-pentest
description: Run an authorized, scoped web application security test with evidence-based findings and strict active-testing guardrails.
metadata: {"cybara":{"requires":{"anyBins":["curl","python3"]}}}
---

# Authorized Web Pentest

Use this only for defensive testing of applications the user owns or has written authorization to test.

## Authorization Gate

Before active testing, ask the user to confirm:

> Confirm: the target URL is `<target>`, you own this application or have written authorization to test it, and active security testing is allowed during this session.

Do not send payloads or scans until the user confirms. Passive source review and reading public pages is fine.

## Scope File

Create an engagement directory:

```bash
ENGAGEMENT="web-pentest-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
printf "%s\n" "<hostname>" > "$ENGAGEMENT/scope.txt"
```

Every active request must target a host in `scope.txt`. Stop on off-scope redirects.

## Phases

1. Setup:
   - Record authorization, target, scope, and time window.
2. Passive/source recon:
   - Map routes, auth, sinks, trust boundaries, and deployment config from code.
3. Read-only live recon:
   - Headers, robots/sitemap, public links, login surface, XHR endpoints.
4. Vulnerability analysis:
   - Injection, XSS, auth/authz, SSRF, file handling, deserialization, CORS, security headers.
5. Proof:
   - Every finding needs a reproducible request/response or code path.
   - No destructive payloads without explicit approval.
6. Report:
   - Findings, severity, impact, evidence, reproduction, minimal fix.

## Rules

- No exploit, no report. Suspicions without proof are notes, not findings.
- Rate-limit active requests.
- Redact credentials and tokens in chat. Store full values only in local evidence files when needed.
- Cloud metadata hosts are off-limits unless explicitly authorized and owned.
- A clean run means "no exploitable issue found in this scope/time/method," not "secure."