pentest-report
Penetration Testing Report Skill
When generating a penetration testing report, follow OWASP standards and methodology. This skill produces a professional-grade report suitable for compliance reviews, stakeholder communication, and remediation planning.
1. Scope & Methodology Discovery
Determine Scope
# Application type
cat package.json pyproject.toml Cargo.toml go.mod pom.xml composer.json Gemfile 2>/dev/null | head -30
# Detect web framework (determines attack surface)
cat package.json 2>/dev/null | grep -E "express|fastify|next|nuxt|nest|koa|hapi|django|flask|fastapi|rails|laravel|spring|gin|fiber|echo"
# Detect API type
grep -rn "app.get\|app.post\|@app.route\|@GetMapping\|router\." --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ app/ 2>/dev/null | head -20
# Detect authentication mechanism
grep -rn "jwt\|passport\|oauth\|session\|cookie\|bearer\|auth" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ app/ 2>/dev/null | head -20
# Detect database
grep -rn "postgres\|mysql\|mongo\|redis\|sqlite\|prisma\|sequelize\|typeorm\|mongoose\|sqlalchemy\|knex\|drizzle" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ app/ 2>/dev/null | head -10
# Detect frontend
cat package.json 2>/dev/null | grep -E "react|vue|angular|svelte|next|nuxt"
# Map API endpoints (attack surface)
grep -rn "router\.\(get\|post\|put\|delete\|patch\)\|app\.\(get\|post\|put\|delete\|patch\)\|@app\.route\|@GetMapping\|@PostMapping\|@PutMapping\|@DeleteMapping" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ app/ 2>/dev/null
# Count total endpoints
grep -rn "router\.\(get\|post\|put\|delete\|patch\)\|app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" --include="*.py" src/ app/ 2>/dev/null | wc -l
# Infrastructure
ls Dockerfile docker-compose.yml docker-compose.yaml k8s/ terraform/ nginx.conf 2>/dev/null
Testing Methodology
This report follows:
- OWASP Web Security Testing Guide (WSTG) v4.2 — structured testing methodology
- OWASP Top 10 (2021) — most critical web application security risks
- OWASP Application Security Verification Standard (ASVS) v4.0 — detailed security requirements
- CVSS v3.1 — Common Vulnerability Scoring System for severity rating
2. OWASP Top 10 (2021) Assessment
Test each category systematically:
A01:2021 — Broken Access Control
WSTG Tests:
- WSTG-ATHZ-01: Testing Directory Traversal/File Include
- WSTG-ATHZ-02: Testing for Bypassing Authorization Schema
- WSTG-ATHZ-03: Testing for Privilege Escalation
- WSTG-ATHZ-04: Testing for Insecure Direct Object References (IDOR)
# Check for missing authorization middleware
grep -rn "router\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" src/api/ src/routes/ 2>/dev/null | grep -v "auth\|middleware\|protect\|guard\|verify"
# Check for IDOR vulnerabilities — direct ID usage without ownership check
grep -rn "req\.params\.id\|req\.params\.userId\|request\.args\.get.*id" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for path traversal
grep -rn "req\.params\|req\.query\|request\.args" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "file\|path\|dir\|upload\|download"
# Check for missing role-based access control
grep -rn "role\|permission\|isAdmin\|hasRole\|authorize\|can(" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for CORS misconfiguration
grep -rn "Access-Control-Allow-Origin\|cors(" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for missing CSRF protection
grep -rn "csrf\|csrfToken\|_token\|antiforgery" --include="*.ts" --include="*.js" --include="*.py" --include="*.html" src/ 2>/dev/null
What to flag:
- Endpoints accessible without authentication
- Missing ownership verification on resource access (IDOR)
- Horizontal privilege escalation (user A accessing user B's data)
- Vertical privilege escalation (regular user accessing admin functions)
- CORS with wildcard origin on authenticated endpoints
- Missing CSRF tokens on state-changing operations
- Directory traversal in file operations
- Missing rate limiting on sensitive endpoints
A02:2021 — Cryptographic Failures
WSTG Tests:
- WSTG-CRYP-01: Testing for Weak Transport Layer Security
- WSTG-CRYP-02: Testing for Padding Oracle
- WSTG-CRYP-03: Testing for Sensitive Information via Unencrypted Channels
- WSTG-CRYP-04: Testing for Weak Encryption
# Check for weak hashing algorithms
grep -rn "md5\|sha1\|SHA1\|MD5" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null | grep -v "node_modules\|test\|spec"
# Check for weak encryption
grep -rn "DES\|RC4\|ECB\|Blowfish" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null
# Check for hardcoded encryption keys
grep -rn "encryption_key\|ENCRYPTION_KEY\|secret_key\|SECRET_KEY\|private_key" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -v "process\.env\|os\.environ\|config\.\|\.env"
# Check for insecure random
grep -rn "Math\.random\|random\.random\|rand()\|srand" --include="*.ts" --include="*.js" --include="*.py" --include="*.php" src/ 2>/dev/null
# Check password hashing
grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for sensitive data in plain text
grep -rn "password.*=\|creditCard\|ssn\|social_security\|credit_card" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -v "test\|spec\|mock\|hash\|bcrypt"
# Check TLS configuration
grep -rn "http://\|ssl.*false\|verify.*false\|rejectUnauthorized.*false\|VERIFY_NONE" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null
What to flag:
- Passwords stored with MD5/SHA1 instead of bcrypt/argon2
- Sensitive data transmitted over HTTP
- Hardcoded encryption keys or secrets
- Weak TLS configuration
- Math.random() for security-sensitive values
- Sensitive data stored unencrypted at rest
- Missing HSTS headers
A03:2021 — Injection
WSTG Tests:
- WSTG-INPV-05: Testing for SQL Injection
- WSTG-INPV-06: Testing for LDAP Injection
- WSTG-INPV-07: Testing for XML Injection
- WSTG-INPV-12: Testing for Command Injection
- WSTG-INPV-11: Testing for Code Injection
# SQL Injection — string concatenation in queries
grep -rn "SELECT.*\+\|INSERT.*\+\|UPDATE.*\+\|DELETE.*\+\|WHERE.*\+\|\`SELECT\|\`INSERT\|\`UPDATE\|\`DELETE" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" --include="*.php" src/ 2>/dev/null | grep -v "test\|spec\|mock"
# SQL Injection — template literals in queries
grep -rn "query.*\${\|execute.*\${" --include="*.ts" --include="*.js" src/ 2>/dev/null
# NoSQL Injection
grep -rn "find(\|findOne(\|updateOne(\|deleteOne(" --include="*.ts" --include="*.js" src/ 2>/dev/null | grep "req\.\|request\."
# Command Injection
grep -rn "exec(\|execSync\|spawn(\|system(\|popen\|subprocess\.\(call\|run\|Popen\)" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# XSS — innerHTML and dangerouslySetInnerHTML
grep -rn "innerHTML\|dangerouslySetInnerHTML\|v-html\|\.html(\|{!!.*!!}" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.vue" --include="*.php" src/ 2>/dev/null
# Template Injection
grep -rn "render_template_string\|Template(\|Jinja2\|eval(" --include="*.py" --include="*.js" --include="*.ts" src/ 2>/dev/null
# LDAP Injection
grep -rn "ldap\.\|LDAP\.\|search_s\|search_ext" --include="*.py" --include="*.java" src/ 2>/dev/null
# XPath Injection
grep -rn "xpath\|XPath\|selectNodes\|evaluate(" --include="*.ts" --include="*.js" --include="*.java" src/ 2>/dev/null
What to flag:
- String concatenation or template literals in SQL queries
- User input passed directly to MongoDB queries
- User input in exec/spawn/system calls
- Unsanitized HTML rendering (innerHTML, dangerouslySetInnerHTML, v-html)
- Template injection via user-controlled template strings
- Missing parameterized queries
A04:2021 — Insecure Design
# Check for missing rate limiting
grep -rn "rate.limit\|rateLimit\|throttle\|slowDown" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for missing input validation library
cat package.json 2>/dev/null | grep -E "zod|joi|yup|class-validator|express-validator"
cat requirements.txt pyproject.toml 2>/dev/null | grep -E "pydantic|marshmallow|cerberus|voluptuous"
# Check for missing error boundaries / global error handling
grep -rn "errorHandler\|ErrorBoundary\|unhandledRejection\|uncaughtException" --include="*.ts" --include="*.js" --include="*.tsx" src/ 2>/dev/null
# Check for business logic flaws
grep -rn "TODO.*secur\|FIXME.*auth\|HACK.*valid\|XXX.*check" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
What to flag:
- Missing rate limiting on authentication endpoints
- Missing input validation framework
- No global error handler
- Missing account lockout mechanism
- No bot detection on public forms
- Missing business rule enforcement server-side
- Trusting client-side validation only
A05:2021 — Security Misconfiguration
# Debug mode in production configs
grep -rn "DEBUG.*=.*True\|debug.*:.*true\|NODE_ENV.*development" --include="*.py" --include="*.ts" --include="*.js" --include="*.yaml" --include="*.yml" --include="*.json" src/ config/ 2>/dev/null | grep -v "test\|spec\|dev"
# Default credentials
grep -rn "admin.*admin\|password.*password\|root.*root\|default.*password\|changeme" --include="*.ts" --include="*.js" --include="*.py" --include="*.yaml" --include="*.yml" --include="*.json" . 2>/dev/null | grep -v "node_modules\|test\|spec\|\.md"
# Exposed stack traces / error details
grep -rn "stack.*trace\|traceback\|stackTrace\|\.stack\b" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "res\.\|response\.\|send\|json"
# Security headers check
grep -rn "helmet\|SecurityMiddleware\|Content-Security-Policy\|X-Frame-Options\|X-Content-Type-Options\|Strict-Transport-Security" --include="*.ts" --include="*.js" --include="*.py" --include="*.conf" src/ config/ 2>/dev/null
# Permissive CORS
grep -rn "origin.*\*\|Access-Control-Allow-Origin.*\*\|cors({.*origin.*true" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Exposed internal paths/ports
grep -rn "localhost\|127\.0\.0\.1\|0\.0\.0\.0" --include="*.ts" --include="*.js" --include="*.py" --include="*.yaml" --include="*.yml" src/ config/ 2>/dev/null | grep -v "test\|spec\|\.md"
# Dockerfile security
cat Dockerfile 2>/dev/null | grep -E "^USER|^FROM|COPY.*\.env|--no-cache"
# .env committed
git ls-files | grep -i "\.env$\|\.env\." | grep -v "\.example\|\.sample\|\.template"
# Exposed API docs in production
grep -rn "swagger\|openapi\|api-docs\|graphql.*playground\|graphiql" --include="*.ts" --include="*.js" --include="*.py" --include="*.yaml" src/ config/ 2>/dev/null
What to flag:
- Debug mode enabled in production configuration
- Default credentials present
- Stack traces returned in API responses
- Missing security headers (CSP, HSTS, X-Frame-Options)
- Wildcard CORS on authenticated endpoints
- .env files committed to Git
- Container running as root
- Swagger/GraphQL playground exposed in production
- Unnecessary services/ports exposed
A06:2021 — Vulnerable and Outdated Components
# Node.js vulnerability audit
npm audit --json 2>/dev/null | head -100
# Python vulnerability audit
pip audit --format json 2>/dev/null | head -100
safety check --json 2>/dev/null | head -100
# Check for outdated packages
npm outdated 2>/dev/null | head -30
pip list --outdated 2>/dev/null | head -30
# Check Node.js version EOL status
node --version 2>/dev/null
# Check for known vulnerable package versions
cat package-lock.json 2>/dev/null | grep -E "jsonwebtoken|lodash|axios|express" | head -20
# Check for unmaintained packages (rough heuristic)
cat package.json 2>/dev/null | grep -E '"dependencies"' -A 100 | grep -E '":' | head -30
What to flag:
- Dependencies with known CVEs (critical and high)
- Packages with no updates in 2+ years
- Runtime/language version past end-of-life
- Missing lockfile (package-lock.json, yarn.lock)
- Unpinned dependency versions
A07:2021 — Identification and Authentication Failures
# Password policy
grep -rn "password.*length\|password.*min\|minLength.*password\|PASSWORD_MIN" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Session management
grep -rn "session\|cookie.*httpOnly\|cookie.*secure\|cookie.*sameSite\|maxAge\|expires" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# JWT configuration
grep -rn "jwt\.\|jsonwebtoken\|JWT_SECRET\|JWT_EXPIR\|expiresIn\|algorithm.*HS\|algorithm.*RS" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Brute force protection
grep -rn "lockout\|max.*attempt\|failed.*login\|login.*attempt\|account.*lock" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Password reset flow
grep -rn "reset.*password\|forgot.*password\|password.*reset\|reset.*token" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Multi-factor authentication
grep -rn "mfa\|2fa\|two.factor\|totp\|authenticator" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Token storage
grep -rn "localStorage\.\(set\|get\)Item.*token\|sessionStorage.*token" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" src/ 2>/dev/null
What to flag:
- No minimum password length or complexity requirements
- Missing brute force protection on login
- Tokens stored in localStorage (should use httpOnly cookies)
- JWT with no expiration or very long expiration
- JWT using weak algorithm (HS256 with short secret)
- Missing session invalidation on logout
- Password reset tokens that don't expire
- Same error message for "user not found" and "wrong password" (information leakage)
- Missing MFA option for sensitive operations
A08:2021 — Software and Data Integrity Failures
# Check for insecure deserialization
grep -rn "JSON\.parse\|pickle\.load\|yaml\.load\|unserialize\|ObjectInputStream\|eval(" --include="*.ts" --include="*.js" --include="*.py" --include="*.php" --include="*.java" src/ 2>/dev/null
# Check for CI/CD security
cat .github/workflows/*.yml .gitlab-ci.yml 2>/dev/null | grep -E "secrets\.|pull_request_target|npm install|pip install" | head -20
# Check for subresource integrity
grep -rn "<script.*src=\|<link.*href=" --include="*.html" --include="*.tsx" --include="*.jsx" src/ public/ 2>/dev/null | grep -v "integrity="
# Check for webhook signature verification
grep -rn "webhook\|signature\|hmac\|verify.*signature" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
What to flag:
- Unsafe deserialization of user input (pickle, yaml.load without SafeLoader, eval)
- CI/CD pipelines running untrusted code
- CDN scripts without subresource integrity (SRI) hashes
- Webhook endpoints not verifying signatures
- Missing code signing or integrity checks on updates
A09:2021 — Security Logging and Monitoring Failures
# Check for logging framework
grep -rn "winston\|pino\|bunyan\|morgan\|log4j\|logback\|logging\.\|logger\." --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null | head -10
# Check for security event logging
grep -rn "login.*log\|auth.*log\|failed.*log\|unauthorized.*log\|forbidden.*log" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for sensitive data in logs
grep -rn "log.*password\|log.*token\|log.*secret\|log.*credit\|log.*ssn\|console\.log.*req\.body" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for error monitoring
cat package.json 2>/dev/null | grep -E "sentry|datadog|newrelic|bugsnag|rollbar"
# Check for audit trail
grep -rn "audit\|trail\|history\|changelog\|activity.*log" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
What to flag:
- No structured logging framework in use
- Authentication events not logged (login, logout, failed attempts)
- Sensitive data appearing in logs (passwords, tokens, PII)
- No error monitoring service configured
- Missing audit trail for sensitive operations (admin actions, data changes)
- Log files accessible without authentication
- No alerting on security events
A10:2021 — Server-Side Request Forgery (SSRF)
# Check for SSRF-prone code
grep -rn "fetch(\|axios\.\|request(\|http\.get\|urllib\|requests\.get\|HttpClient" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null | grep -i "req\.\|params\|body\|query\|input\|user"
# Check for URL validation
grep -rn "url.*valid\|isURL\|parseURL\|new URL" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null
# Check for internal network access prevention
grep -rn "127\.0\.0\.1\|localhost\|169\.254\|10\.\|172\.16\|192\.168\|0\.0\.0\.0\|::1" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "block\|deny\|reject\|filter\|whitelist\|allowlist"
What to flag:
- User-controlled URLs passed to fetch/axios/requests
- No URL validation or allowlist for outgoing requests
- No blocking of internal/private IP ranges
- Ability to specify protocols (file://, gopher://, dict://)
3. OWASP ASVS Compliance Check
Map findings to ASVS verification levels:
Level 1 — Minimum (All Applications)
| ASVS ID | Requirement | Status |
|---|---|---|
| V1.2.1 | Verify use of unique or special low-privilege OS account for all components | ⬜ |
| V2.1.1 | Verify user set passwords are at least 12 characters | ⬜ |
| V2.1.2 | Verify passwords of at least 64 characters are permitted | ⬜ |
| V2.1.7 | Verify passwords submitted during registration are checked against breached password set | ⬜ |
| V3.2.1 | Verify the application generates new session tokens on user authentication | ⬜ |
| V3.4.1 | Verify cookie-based session tokens have Secure attribute | ⬜ |
| V3.4.2 | Verify cookie-based session tokens have HttpOnly attribute | ⬜ |
| V3.4.3 | Verify cookie-based session tokens use SameSite attribute | ⬜ |
| V4.1.1 | Verify the application enforces access control rules on a trusted service layer | ⬜ |
| V4.1.2 | Verify all user/data attributes cannot be manipulated by end users | ⬜ |
| V5.1.1 | Verify the application has defenses against HTTP parameter pollution | ⬜ |
| V5.2.1 | Verify all untrusted HTML input is properly sanitized using safe HTML library | ⬜ |
| V5.3.1 | Verify output encoding relevant for the interpreter and context used | ⬜ |
| V5.3.4 | Verify data selection or database queries use parameterized queries | ⬜ |
| V8.3.1 | Verify sensitive data is sent using TLS | ⬜ |
| V8.3.4 | Verify all sensitive data is created with associated mechanisms for removal | ⬜ |
| V9.1.1 | Verify TLS is used for all client connectivity | ⬜ |
| V14.2.1 | Verify all components are up to date | ⬜ |
Level 2 — Standard (Applications Handling Sensitive Data)
| ASVS ID | Requirement | Status |
|---|---|---|
| V1.11.1 | Verify definition and documentation of all application components | ⬜ |
| V2.2.1 | Verify anti-automation controls protect against breached credential testing | ⬜ |
| V2.5.1 | Verify password change requires the current password | ⬜ |
| V2.8.1 | Verify time-based OTPs have a defined lifetime | ⬜ |
| V3.3.1 | Verify logout and expiration invalidates stateful session tokens | ⬜ |
| V3.5.1 | Verify the application allows users to revoke OAuth tokens | ⬜ |
| V4.2.1 | Verify sensitive data and APIs are protected against IDOR attacks | ⬜ |
| V5.2.4 | Verify the application avoids use of eval() or dynamic code execution | ⬜ |
| V5.5.1 | Verify serialized objects use integrity checks or encryption | ⬜ |
| V7.1.1 | Verify the application does not log credentials or payment details | ⬜ |
| V7.1.2 | Verify the application does not log other sensitive data | ⬜ |
| V8.1.1 | Verify the application protects sensitive data from being cached in server components | ⬜ |
| V9.1.2 | Verify TLS configuration uses current recommended cipher suites | ⬜ |
| V11.1.1 | Verify the application will only process business logic flows in sequential order | ⬜ |
| V13.1.1 | Verify all input is validated (API and web) | ⬜ |
| V14.4.1 | Verify every HTTP response contains a Content-Type header | ⬜ |
Level 3 — Advanced (Critical Applications: Healthcare, Finance, Military)
| ASVS ID | Requirement | Status |
|---|---|---|
| V1.5.1 | Verify input and output requirements are documented | ⬜ |
| V1.14.1 | Verify segregation of components of differing trust levels | ⬜ |
| V6.2.1 | Verify all cryptographic modules fail securely | ⬜ |
| V6.2.5 | Verify known insecure block modes, padding modes, or ciphers are not used | ⬜ |
| V8.2.1 | Verify the application sets sufficient anti-caching headers | ⬜ |
| V9.2.1 | Verify connections to and from the server use trusted TLS certificates | ⬜ |
| V10.3.1 | Verify the application source code and third-party libraries are free of backdoors | ⬜ |
| V14.5.1 | Verify the application server only accepts defined HTTP methods | ⬜ |
Mark each as: ✅ Pass | ❌ Fail | ⚠️ Partial | ⬜ Not Tested
4. CVSS v3.1 Scoring
Score each finding using CVSS v3.1:
Score Components
| Metric | Values |
|---|---|
| Attack Vector (AV) | Network (N) / Adjacent (A) / Local (L) / Physical (P) |
| Attack Complexity (AC) | Low (L) / High (H) |
| Privileges Required (PR) | None (N) / Low (L) / High (H) |
| User Interaction (UI) | None (N) / Required (R) |
| Scope (S) | Unchanged (U) / Changed (C) |
| Confidentiality (C) | None (N) / Low (L) / High (H) |
| Integrity (I) | None (N) / Low (L) / High (H) |
| Availability (A) | None (N) / Low (L) / High (H) |
Severity Ratings
| CVSS Score | Rating | Color |
|---|---|---|
| 0.0 | None | ⬜ |
| 0.1 - 3.9 | Low | 🟢 |
| 4.0 - 6.9 | Medium | 🟡 |
| 7.0 - 8.9 | High | 🟠 |
| 9.0 - 10.0 | Critical | 🔴 |
Common CVSS Vectors for Web Vulnerabilities
SQL Injection (unauthenticated):
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical
Stored XSS:
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N → 5.4 Medium
IDOR (authenticated user):
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N → 6.5 Medium
Missing Rate Limiting on Login:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5 High
Exposed Secrets in Source:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical
Weak Password Storage (MD5):
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N → 7.4 High
Missing CSRF:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N → 6.5 Medium
Missing Security Headers:
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N → 4.2 Medium
Debug Mode in Production:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N → 5.3 Medium
Vulnerable Dependency (RCE):
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical
5. Report Format
Generate the full report in this structure:
# Penetration Testing Report
## Executive Summary
**Application:** [Application Name]
**Version:** [Version/Commit]
**Assessment Date:** [Date]
**Assessor:** [Name/Team]
**Methodology:** OWASP WSTG v4.2, OWASP Top 10 (2021), OWASP ASVS v4.0
**Scope:** [What was tested — application, API, infrastructure]
**Classification:** [Confidential / Internal / Public]
### Overall Risk Rating
| Rating | [CRITICAL / HIGH / MEDIUM / LOW] |
|--------|----------------------------------|
| Total Findings | X |
| Critical | X |
| High | X |
| Medium | X |
| Low | X |
| Informational | X |
### Risk Distribution
🔴 Critical: ████░░░░░░ X findings
🟠 High: ██████░░░░ X findings
🟡 Medium: ████████░░ X findings
🟢 Low: ██░░░░░░░░ X findings
⬜ Info: █░░░░░░░░░ X findings
### Key Findings Summary
| # | Finding | OWASP Category | CVSS | Severity | Status |
|---|---------|---------------|------|----------|--------|
| 1 | [Title] | A01 - Broken Access Control | 9.1 | 🔴 Critical | Open |
| 2 | [Title] | A03 - Injection | 8.6 | 🟠 High | Open |
| 3 | [Title] | A02 - Cryptographic Failures | 7.4 | 🟠 High | Open |
| ... | ... | ... | ... | ... | ... |
---
## Scope and Methodology
### In Scope
- [Application URL / repository]
- [API endpoints]
- [Authentication flows]
- [Business logic]
### Out of Scope
- [Infrastructure / hosting]
- [Third-party services]
- [Physical security]
- [Social engineering]
### Testing Approach
- Static Application Security Testing (SAST) — source code review
- Dependency vulnerability scanning
- Configuration review
- OWASP Top 10 coverage
- OWASP ASVS Level [1/2/3] verification
### Tools Used
- Manual code review
- grep-based pattern scanning
- npm audit / pip audit
- [Any additional tools]
---
## Detailed Findings
### Finding 1: [Title]
| Attribute | Value |
|-----------|-------|
| **ID** | PT-001 |
| **Severity** | 🔴 Critical |
| **CVSS Score** | 9.8 |
| **CVSS Vector** | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| **OWASP Top 10** | A03:2021 — Injection |
| **OWASP WSTG** | WSTG-INPV-05 |
| **OWASP ASVS** | V5.3.4 |
| **CWE** | CWE-89: SQL Injection |
| **Location** | `src/api/routes/users.ts:45` |
| **Status** | Open |
**Description:**
[Detailed description of the vulnerability, how it was discovered,
and what it allows an attacker to do]
**Evidence:**
// Vulnerable code
const user = await db.query(SELECT * FROM users WHERE id = '${req.params.id}');
**Impact:**
[What an attacker could achieve — data breach, account takeover, RCE, etc.]
**Proof of Concept:**
Example attack request
curl "https://app.example.com/api/users/1' OR '1'='1"
**Remediation:**
// Fixed code const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
**Remediation Priority:** Immediate
**Estimated Effort:** [time to fix]
---
[Repeat for each finding...]
---
## OWASP Top 10 Coverage Matrix
| Category | Tested | Findings | Highest Severity |
|----------|--------|----------|-----------------|
| A01 — Broken Access Control | ✅ | X | [severity] |
| A02 — Cryptographic Failures | ✅ | X | [severity] |
| A03 — Injection | ✅ | X | [severity] |
| A04 — Insecure Design | ✅ | X | [severity] |
| A05 — Security Misconfiguration | ✅ | X | [severity] |
| A06 — Vulnerable Components | ✅ | X | [severity] |
| A07 — Auth Failures | ✅ | X | [severity] |
| A08 — Data Integrity Failures | ✅ | X | [severity] |
| A09 — Logging & Monitoring | ✅ | X | [severity] |
| A10 — SSRF | ✅ | X | [severity] |
## ASVS Compliance Summary
| Level | Requirements | Passed | Failed | Not Tested | Compliance |
|-------|-------------|--------|--------|-----------|------------|
| L1 | X | X | X | X | X% |
| L2 | X | X | X | X | X% |
| L3 | X | X | X | X | X% |
## Remediation Roadmap
### Immediate (0-48 hours)
| # | Finding | Severity | Effort | Owner |
|---|---------|----------|--------|-------|
| 1 | [Critical finding] | 🔴 Critical | 2h | |
| 2 | [Critical finding] | 🔴 Critical | 4h | |
### Short-Term (1-2 weeks)
| # | Finding | Severity | Effort | Owner |
|---|---------|----------|--------|-------|
| 3 | [High finding] | 🟠 High | 1d | |
| 4 | [High finding] | 🟠 High | 2d | |
### Medium-Term (1 month)
| # | Finding | Severity | Effort | Owner |
|---|---------|----------|--------|-------|
| 5 | [Medium finding] | 🟡 Medium | 2d | |
| 6 | [Medium finding] | 🟡 Medium | 3d | |
### Long-Term (1-3 months)
| # | Finding | Severity | Effort | Owner |
|---|---------|----------|--------|-------|
| 7 | [Low finding] | 🟢 Low | 1d | |
| 8 | [Architectural change] | 🟡 Medium | 1w | |
## Positive Findings
List security controls that ARE properly implemented:
- [Example: Passwords are hashed with bcrypt with cost factor 12]
- [Example: All API endpoints require authentication]
- [Example: HTTPS is enforced with HSTS]
- [Example: SQL queries use parameterized statements]
- [Example: Dependency lockfile is committed]
## Recommendations
### Quick Wins
1. [Action that takes <1 hour and fixes a critical issue]
2. [Action that takes <1 hour and fixes a critical issue]
### Process Improvements
1. [Add dependency scanning to CI/CD pipeline]
2. [Implement security code review checklist]
3. [Set up automated SAST scanning]
4. [Schedule quarterly penetration testing]
### Architecture Improvements
1. [Implement WAF for additional protection layer]
2. [Add centralized logging and alerting]
3. [Implement secrets management solution]
---
## Appendix
### A. Testing Checklist (WSTG)
[Full list of WSTG test cases with pass/fail/N/A status]
### B. Dependency Vulnerability Report
[Full output of npm audit / pip audit]
### C. ASVS Detailed Results
[Full ASVS checklist with individual requirement status]
### D. Glossary
| Term | Definition |
|------|-----------|
| CVSS | Common Vulnerability Scoring System |
| CWE | Common Weakness Enumeration |
| OWASP | Open Worldwide Application Security Project |
| ASVS | Application Security Verification Standard |
| WSTG | Web Security Testing Guide |
| SSRF | Server-Side Request Forgery |
| IDOR | Insecure Direct Object Reference |
| XSS | Cross-Site Scripting |
| CSRF | Cross-Site Request Forgery |
| SQLi | SQL Injection |
---
**Report prepared following OWASP standards.**
**This report is confidential and intended for authorized recipients only.**
Adaptation Rules
- Detect the ASVS level — Level 1 for basic apps, Level 2 for apps handling sensitive data, Level 3 for critical systems (healthcare, finance)
- Focus on the stack — only run checks relevant to the detected technology
- Use real file paths — reference exact lines where vulnerabilities are found
- Provide working fixes — not just descriptions, but actual corrected code
- Include positive findings — audits should acknowledge what's done well
- Prioritize by exploitability — a remotely exploitable unauthenticated vulnerability is more urgent than a local authenticated one
- Be specific — "SQL injection in user search endpoint at line 45" not "the app may have SQL injection"
- Include CVSS vectors — allow teams to validate and adjust severity ratings
- Generate remediation tickets — each finding should be actionable as a ticket
- Flag false positives — if a pattern looks vulnerable but has mitigations, note it
Summary
End every penetration testing report with:
- Overall risk rating — Critical / High / Medium / Low
- Finding count — total and by severity
- Top 3 most critical findings — immediate action items
- OWASP Top 10 coverage — which categories had findings
- ASVS compliance percentage — for the targeted level
- Remediation timeline — immediate, short-term, medium-term, long-term
- Retest recommendation — when to schedule the next assessment
More from aakash-dhar/claude-skills
security-audit
Scans code for security vulnerabilities including injection attacks, authentication flaws, exposed secrets, insecure dependencies, and data exposure. Use when the user says "security review", "is this secure?", "check for vulnerabilities", "audit this", or before deploying to production.
118vulnerability-report
Scans project dependencies for known vulnerabilities (CVEs), categorizes them into three severity-based reports (Critical/High, Medium, Low), and generates detailed markdown documents with remediation guidance. Saves output to project-decisions/ folder. Use when the user says "vulnerability report", "dependency vulnerabilities", "CVE report", "package vulnerabilities", "npm audit report", "dependency scan", "vulnerable packages", "security vulnerabilities in dependencies", or "generate vulnerability reports".
5code-review
Reviews code for bugs, security issues, performance problems, and adherence to best practices. Use when the user asks to "review this code", "check my code", "is this code good?", or before submitting a PR.
4risk-register
Creates and maintains a living project risk register by analyzing the codebase, dependencies, team structure, timeline, and technical decisions. Identifies risks, scores them by likelihood and impact, assigns owners, tracks mitigations, and flags risks that have changed since last assessment. Saves output to project-decisions/ folder. Use when the user says "risk register", "project risks", "what could go wrong", "risk assessment", "identify risks", "update risks", "risk review", "what are our risks", or "flag risks for the project".
4tech-decision
Evaluates technical proposals, "should we do X instead of Y?" questions, tool comparisons, and architecture suggestions. Analyzes feasibility, compares options with structured pros/cons, estimates effort and risk, and provides a clear recommendation. Saves output to project-decisions/ folder. Use when the user says "should we", "what if we", "is it worth", "should we switch to", "compare X vs Y", "evaluate this proposal", "tech decision", or brings up a technical suggestion from a team discussion.
1incident-report
Generates structured incident postmortem reports by analyzing git history, recent deployments, code changes, logs, and error patterns. Produces a blameless postmortem with timeline, root cause analysis, impact assessment, remediation actions, and prevention measures. Saves output to project-decisions/ folder. Use when the user says "incident report", "postmortem", "what went wrong", "outage report", "root cause analysis", "RCA", "write a post-mortem", "incident review", "we had an incident", "production issue", or "site went down".
1