Pentest

Pentest

Black-box security audit of a running web application, from the outside, via HTTP.

Default language: match the user's request language (Russian or English). Pass --lang ru|en to override. Reports live in {cwd}/pentest-output/{target-slug}-{YYYY-MM-DD}/.

Assumption: the user has authorization from the target's owner. Do not ask for legalese — trust the user. But never run this skill against a target the user hasn't explicitly named.

Workflow

Phase 0 — Scope

Before touching the target, confirm:

• Target URL — full https://… URL of the deployed app (the mini app entry URL, not t.me/...).
• Aggression level — default L1. Let the user override:
  • L0 passive: public metadata only, zero probes of the app itself
  • L1 safe (default): single-request probes, read-only, no mutations
  • L2 authorized: mutations on the auditor's own test account (profile updates, intros, etc.)
  • L3 destructive: real injection payloads, cross-tenant access attempts, rate-limit probing without load testing
• Target type hint — telegram-miniapp | nextjs-vercel | supabase | generic. Auto-detect from headers if not provided.
• Language — ru or en (default: match user's language).
• Credentials needed? — if the target needs auth to explore (most apps do), ask the user to paste the auth artifact once:
  • Telegram mini apps: the launch URL fragment (https://…/#tgWebAppData=…) captured from DevTools when the app opens
  • Cookie-based apps: a session cookie or token from the user's logged-in session
  • Store it in secrets.txt under the workspace, add .gitignore to exclude it
  • Never include the raw auth artifact in any report file.

Phase 1 — Workspace

slug=$(echo "<target host>" | tr -cd 'a-z0-9-')
day=$(date +%Y-%m-%d)
workdir="${PWD}/pentest-output/${slug}-${day}"
mkdir -p "${workdir}"/{recon,bundle,scripts,findings,fixes}
echo 'secrets.txt
*.local.*
cookies.txt' > "${workdir}/.gitignore"

Write ${workdir}/README.md with: target URL, scope, level, language, start time, operator.

Phase 2 — Recon (L0 — always run)

Read ${CLAUDE_PLUGIN_ROOT:-.}/skills/pentest/references/checklist-generic.md for the full command list. Minimum:

1. DNS (A, AAAA, CNAME, NS) and provider fingerprint
2. curl -D headers_root.txt -o body_root.html <target> — save headers + body
3. Probe well-known paths: robots.txt, sitemap.xml, /.well-known/security.txt, favicon.ico, manifest.json
4. Grep the root HTML for asset references → full JS/CSS chunk inventory
5. Extract og:* meta, <script src>, <link href>, any inline data
6. Check security headers on both root and sample API endpoint: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, CORS

Fingerprint the stack from response headers:

• server: Vercel + x-matched-path + x-nextjs-* → Next.js on Vercel → load references/nextjs-vercel.md
• URLs like …supabase.co → Supabase backend → load references/supabase.md
• https://telegram.org/js/telegram-web-app.js or tgWebAppData fragment → Telegram mini app → load references/telegram-miniapp.md

Apply stack-specific reference only when fingerprint matches. Don't read all references upfront.

Phase 3 — Bundle analysis

Download all JS chunks referenced from the root HTML to bundle/. For each:

for f in bundle/*.js; do
  curl -sS -o "$f.map" "https://<host>/path/to/$(basename $f).map?<dpl>"
  [ -s "$f.map" ] && echo "source map exposed: $f"
done

Grep the bundle for:

• API routes: /api/[^"]+
• fetch( / axios( call sites
• Absolute URLs of third-party services
• Secrets patterns: eyJ[a-zA-Z0-9_-]{40,}, sk_[a-z]+_[a-zA-Z0-9]{20,}, NEXT_PUBLIC_[A-Z_]+, SUPABASE_[A-Z_]*, api_key, service_role
• Auth header name (Authorization, x-telegram-init-data, X-Api-Key, etc.) and how it's injected
• /directory/${...}, /profile/${...} — templated app-level routes

Save the full inventory to recon/api-inventory.md — this becomes the map for Phase 4.

Client wiring audit. Once the auth header is identified (say x-telegram-init-data), grep for fetch( calls that hit /api/ endpoints but do NOT go through the app's auth wrapper (typically apiFetch or similar). Example: a fetch("/api/referrals/attribute", {method:"POST", ...}) with no x-telegram-init-data header, while the server demands it, means the feature is functionally broken on the client. That's a reportable bug (info severity, «broken feature») even if it's not a security vulnerability. Flag these:

# find raw fetch() calls to /api
grep -hoE 'fetch\([^)]{0,300}/api/[^)]{0,300}\)' bundle/*.js | head -20
# compare: which ones go through apiFetch (auth wrapper)?
grep -hoE 'apiFetch\([^)]{0,300}\)' bundle/*.js | head -20

If a route appears in plain fetch( but is also listed as requiring auth in your Phase 4 map, note «client-wiring mismatch: server requires auth, client sends none — feature broken».

Phase 4 — Endpoint probing (L1 default)

For every /api/* endpoint found:

1. Unauthenticated GET — record status code, size, body preview
2. Authenticated GET (with user's auth artifact) — record the same
3. Compare: endpoints that return 200 unauth AND contain PII are privacy leaks

Then for any auth/login endpoint (/api/auth/*, /api/session, etc.):

• Empty body → expected 400, flag 500 as an input-validation bug
• Missing credentials → expected 401
• Bad credentials → expected 401
• Credentials with tampered fields but valid signature → expected 401 (this tests the signature actually covers the tampered field)

If stack = telegram-miniapp, run the full auth test matrix from references/telegram-miniapp.md (empty initData, no hash, fake hash, tampered user_id, stale auth_date replay).

Phase 5 — Authorization / IDOR (L1 default)

Collect any IDs visible in Phase 4 responses (userId, memberId, eventId, intro_id, etc.) and try:

• GET /api/members/{otherUserId} with your own auth — do you see their data? Expected: 200 (if public) or 404/403 (if protected)
• GET /api/{thing}?userId={otherUserId} — does the filter actually filter? Or is it silently ignored?
• GET /api/{thing}?limit=999999, ?limit=-1, ?offset=abc — input validation smoke. Note 500s as bugs.
• ?role=admin, ?membershipStatus=banned — does passing a privilege filter return different data?
• Path confusion: /api/{thing}/..%2F..%2Fetc%2Fpasswd, /api/{thing}/%00.json

Do not fetch another real user's sensitive data past proof-of-access. Stop at the first 200 that proves the vulnerability and record just the structure of the response, not the content. Redact names/emails/ids of real users in the report.

Phase 6 — L2 (mutations on own account, only if user asked for L2)

On the auditor's own test account:

• POST endpoints: profile update, intro send, referral attribute, upload
• Test: server-side validation vs client-side. Can you send fields not shown in the client form?
• Test: are reserved/internal fields accepted? (is_admin, role, membership_status, credits, tier)
• Test: can you change another user's resource by sending their ID in the body? (IDOR on mutations)
• Test: file upload — MIME sniffing, path traversal in filename, SVG-with-script upload, oversize file

Always label each mutation request in EVIDENCE.md with what it did and which object it touched, so it's easy to clean up afterward.

Phase 7 — L3 (destructive, only if user asked for L3)

• SQL/NoSQL injection payloads (' OR 1=1--, '; DROP --, {"$ne": null}) on fields that hit the DB
• SSRF via URL parameters (url=http://169.254.169.254/latest/meta-data/)
• XSS in stored fields (<script>alert(1)</script>, javascript:alert(1) in avatarUrl) — check where it reflects
• Prototype pollution via JSON body ({"__proto__":{"isAdmin":true}})
• Cross-tenant: attempt to read/modify a non-test user's data. Stop at proof-of-access, don't exfiltrate.

Single requests only. No load / brute-force / enumeration loops. If a finding needs automation to be proven, write it up as a theoretical finding with the single-request PoC and note the limitation.

Phase 8 — Generate deliverables

Three artifacts, two locations:

• ${workdir}/findings/REPORT.md — human-readable, for the target's owner. Use references/report-template.md as the skeleton. Order findings by severity descending. Each finding has: description, why it matters, PoC steps, recommended fix (with code snippet). End with "What works well ✅" and "What I didn't test" sections.
• ${workdir}/findings/EVIDENCE.md — raw request/response log, one section per finding. Use references/evidence-template.md. Redact real user PII. Keep auth artifacts out (they're in secrets.txt, .gitignored).
• ${workdir}/fixes/ (sibling of findings/, NOT nested) — machine-actionable per-finding fix plan, designed to be consumed by another coding agent:
  • ${workdir}/fixes/INDEX.md — markdown table of all fixes sorted by priority with a one-line summary each
  • ${workdir}/fixes/NN-slug.md — one file per finding, two-digit priority prefix (e.g. 01-auth-date-ttl.md, 02-public-member-list.md)
  • Template: references/fix-template.md

After writing, print the three absolute paths in chat: ${workdir}/findings/REPORT.md, ${workdir}/findings/EVIDENCE.md, ${workdir}/fixes/INDEX.md. Don't dump report contents into chat.

Consuming fixes/ with another agent

The per-finding fix files are self-contained. To apply fixes in a different session, user can say:

"Read fixes/INDEX.md and apply the fixes one by one, running tests between each."

Each fix file has:

• severity, title, location (URL/file), summary
• patch — concrete code change (or pseudo-patch if the repo is not available)
• verification — commands or HTTP probes that confirm the fix landed

Rules

1. Never run load / stress tests here — route the user to loadtest instead. A burst of 100 requests in a tight loop is load testing, not probing.
2. Redact every human name, email, phone, and telegram handle by default before writing to REPORT.md or EVIDENCE.md. Even if a name appears in the target's own public listing (e.g., the owner's name in their own member directory), redact. The only exception is a name explicitly named by the user as «OK to keep»: «you can keep Aleksey's name» — otherwise mask to <redacted-name>, <redacted-email>, <redacted-uuid>. Default wins; opt-out is per-name.
3. Never write the raw auth artifact to any file outside secrets.txt. Never paste it in chat.
4. Never exploit a finding past proof-of-access. If you prove GET /api/admin/* returns 200, stop — don't iterate through the list.
5. Every mutation (L2+) must be labeled in EVIDENCE.md with (a) endpoint, (b) body sent, (c) object affected, (d) reversibility note.
6. Never escalate levels without a fresh user confirmation in the current turn. If the user invoked L1 and mid-run you find something that looks «L2-interesting», record it as an L1 finding with the single-request PoC and a note «L2 probe needed to confirm». Do not escalate on your own initiative even when the next probe would obviously land.
7. Stop and ask the user before running L2 on any endpoint marked «mutation» if it looks like it touches billing/payment/external service integration.
8. Never use the Claude-only AskUserQuestion, TeamCreate, TaskCreate APIs — this skill runs in both Claude Code and Codex.

Stack-specific references

Load only when the fingerprint from Phase 2 matches:

Templates: