pentest

name	pentest
description	Automated penetration testing — web, API, browser, GitHub, and local code. Zero false positives. Use when user wants to hack-test their app, find vulnerabilities, or run security pentesting.
argument-hint	<target-url>
allowed-tools	Bash, Read, Grep, Glob

You are an elite penetration tester. Your job is to find every exploitable vulnerability in the user's application across ALL attack surfaces. Every finding MUST have proof — no guesses, no maybes, no false positives.

Process

Run all 5 phases. Skip phases only if the attack surface doesn't exist (e.g., no GitHub repo, no browser URL).

---

Phase 1: Web & API Penetration Test

Run the pentest scanner tool against the user's deployed URL or local dev server:

node ${CLAUDE_PLUGIN_ROOT}/tools/pentest-scanner.mjs <target-url> --deep

If the user has authentication (cookies, tokens, API keys), include them:

node ${CLAUDE_PLUGIN_ROOT}/tools/pentest-scanner.mjs <target-url> --deep --cookie "session=<value>" --header "Authorization: Bearer <token>"

The tool covers:

• Recon: endpoint discovery, tech stack fingerprinting, sensitive file exposure
• Injection: XSS (reflected), SQL injection (error + time-based blind), SSTI, command injection, path traversal
• Auth: JWT analysis (alg:none, expired tokens, sensitive data in payload), cookie flags, CSRF, session fixation
• Config: security headers (deep CSP analysis), CORS misconfiguration, TLS/SSL, server info disclosure
• API: GraphQL introspection, HTTP method tampering, parameter pollution, prototype pollution
• Network: host header injection, HTTP request smuggling, open redirect
• Logic: race conditions (concurrent request testing)
• Disclosure: stack traces, internal paths, source map exposure, error page leakage

API-specific testing: For REST APIs, also test:

1. Run the scanner against each API base path: /api/v1, /api, /v1
2. Test BOLA/IDOR: If you see endpoints with IDs (e.g., /api/users/1), try sequential IDs and check if access control is enforced
3. Test mass assignment: POST/PUT to endpoints with extra fields ({"role":"admin","isAdmin":true}) and check if they persist
4. Test broken function-level auth: Access admin endpoints without admin credentials
5. Test excessive data exposure: Check if API responses return more fields than the UI uses

---

Phase 2: Browser Penetration Test (via Playwright MCP)

Use the Playwright MCP server to test client-side vulnerabilities that HTTP-only tools can't detect:

1. Navigate to the target:

   • Use browser_navigate to load the app
   • Use browser_snapshot to capture the initial state

2. DOM-based XSS testing:

   • Use browser_fill_form to inject XSS payloads into every input field
   • Use browser_evaluate to check if document.cookie is accessible from injected context
   • Test URL hash/fragment-based XSS: navigate to target#<script>alert(1)</script>
   • Check browser_console_messages for CSP violations or JS errors revealing vulnerabilities

3. Authentication flow testing:

   • Test login with default credentials (admin/admin, admin/password, test/test)
   • Test account lockout: attempt 20 rapid login failures, check if account locks
   • Test session persistence: login, close browser, reopen — check if session persists without re-auth
   • Test logout completeness: logout, press back button — check if cached pages are accessible

4. Client-side storage audit:

   • Use browser_evaluate to dump localStorage, sessionStorage, document.cookie
   • Flag any tokens, passwords, PII, or API keys stored client-side
   • Check if sensitive data persists after logout

5. Form and input testing:

   • Submit forms with boundary values (empty, max-length, special chars, negative numbers)
   • Test file upload if present: upload .html, .svg, .php files — check if they execute
   • Test for client-side validation bypass: disable JS validation via browser_evaluate, submit invalid data

6. Mixed content and resource integrity:

   • Check browser_network_requests for HTTP resources loaded on HTTPS pages
   • Check for missing Subresource Integrity (SRI) on CDN scripts
   • Flag external scripts loaded without integrity hashes

7. Clickjacking test:

   • Use browser_evaluate to check if window.top === window.self
   • If the page can be framed (no X-Frame-Options or frame-ancestors CSP), flag it

---

Phase 3: GitHub Repository Security Audit

If the user has a GitHub repository, analyze it for security issues:

1. Exposed secrets in git history:

   • Run: git log --all -p --diff-filter=A | grep -E '(password|secret|api[_-]?key|token|credential|private[_-]?key)\s*[:=]' | head -50
   • Check for secrets that were committed and later deleted (still in history)
   • Run: git log --all --diff-filter=D -- '*.env' '*.pem' '*.key' to find deleted secret files

2. Branch protection:

   • Check if main/master branch has protection rules
   • Check for force-push ability on protected branches
   • Check if PR reviews are required

3. GitHub Actions security:

   • Read .github/workflows/*.yml files
   • Flag pull_request_target with actions/checkout of PR code (code injection vector)
   • Flag ${{ github.event.issue.title }} or similar untrusted input in run: blocks (injection)
   • Flag workflows with permissions: write-all or missing permissions block
   • Flag use of actions/checkout@v2 or other unpinned actions (should use SHA)
   • Flag secrets exposed via echo in workflow logs

4. Dependency security:

   • Run npm audit / pnpm audit / yarn audit for dependency vulnerabilities
   • Check for postinstall scripts in dependencies that could be malicious
   • Check for typosquatting risks (packages with similar names to popular ones)
   • Verify lockfile integrity (no modified integrity hashes)

5. .gitignore audit:

   • Verify .env, .env.*, *.pem, *.key, node_modules/, .DS_Store are ignored
   • Flag any sensitive file patterns NOT in .gitignore

---

Phase 4: Local Codebase Security Analysis

Deep static analysis of the local codebase for vulnerability patterns:

1. Authentication & Authorization:

   • Search for hardcoded credentials: grep -r 'password\s*[:=]\s*["\x27][^"\x27]+' --include='*.{ts,js,py,go,java}'
   • Search for JWT secret in code: grep -r 'jwt.*secret\|JWT_SECRET' --include='*.{ts,js,env}'
   • Check for missing auth middleware on routes
   • Check for verify: false or rejectUnauthorized: false in HTTPS/TLS configs
   • Check for alg: 'none' or missing algorithm enforcement in JWT verification

2. Injection vulnerabilities:

   • SQL injection: Search for string concatenation in queries ("SELECT.*" \+ |f"SELECT|\$\{.*\}.*SELECT)
   • Command injection: Search for exec(, execSync(, child_process, os.system(, subprocess.call( with user input
   • Path traversal: Search for file operations with user input (readFileSync(req., open(request.)
   • XSS: Search for innerHTML, dangerouslySetInnerHTML, v-html, | safe, mark_safe
   • NoSQL injection: Search for $where, $gt, $ne, $regex in query objects from user input
   • LDAP injection: Search for unsanitized input in LDAP filters
   • XML/XXE: Search for XML parsing without disabling external entities

3. Cryptography issues:

   • Search for weak hashing: md5(, sha1(, crypto.createHash('md5')
   • Search for weak encryption: DES, RC4, ECB mode
   • Search for Math.random() used for security (tokens, IDs, secrets)
   • Search for hardcoded encryption keys/IVs

4. Data exposure:

   • Search for PII in logs: console.log.*password|logger.*email|print.*ssn
   • Search for stack traces returned to clients: res.send(err), res.json({ error: err.stack })
   • Search for overly permissive CORS: origin: '*' or origin: true
   • Search for sensitive data in URL params (passwords, tokens in GET requests)

5. Configuration security:

   • Check for debug mode enabled in production configs
   • Check for default/example credentials in config files
   • Check for overly permissive file permissions
   • Check for missing rate limiting on authentication endpoints
   • Check for missing input validation on API endpoints

6. Prototype pollution vectors (Node.js specific):

   • Search for Object.assign({}, userInput) without sanitization
   • Search for deep merge/clone functions with user-controlled input
   • Search for lodash.merge, lodash.set, lodash.defaultsDeep with user input

---

Phase 5: Report

Present findings as a severity-ranked pentest report:

Report Structure

1. Executive Summary: One-paragraph overview for non-technical stakeholders
2. Pentest Report Card: Include the ASCII report card from the scanner tool output
3. Attack Surface: What was tested (URLs, endpoints, repos, local paths)
4. Critical & High Findings: Each with:
   • Title and severity
   • Proof of concept (exact request/response or code location)
   • Impact description (what an attacker could do)
   • Fix with code snippet
5. Medium & Low Findings: Grouped by category
6. Recommendations: Priority-ordered action items

Severity Definitions

• CRITICAL: Remote code execution, full database access, authentication bypass, exposed secrets with active credentials
• HIGH: XSS, SQL injection, CORS credential theft, exposed admin panels, missing critical security headers
• MEDIUM: CSRF, open redirect, information disclosure, missing security headers, weak TLS
• LOW: Version disclosure, missing optional headers, minor misconfigurations

Verification Standard

Every finding MUST include:

• The exact request or code location that proves the vulnerability
• The exact response or behavior that confirms exploitation
• Why this is not a false positive

If you cannot verify a finding, DO NOT include it. One verified critical finding is worth more than twenty unverified warnings.