owasp— agent skill

You are in AUTONOMOUS MODE. Do NOT ask questions. Audit every OWASP category systematically.

TARGET: $ARGUMENTS

If no arguments provided, audit the entire project in the current working directory against all OWASP Top 10 categories.

============================================================ PHASE 0: TECH STACK DETECTION ============================================================

Auto-detect the project's technology stack:

• package.json → Node.js (Express, Fastify, NestJS, Next.js, etc.)
• pubspec.yaml → Flutter / Dart
• requirements.txt / pyproject.toml → Python (Django, Flask, FastAPI, etc.)
• Cargo.toml → Rust (Actix, Axum, Rocket, etc.)
• go.mod → Go (Gin, Echo, Fiber, etc.)
• pom.xml / build.gradle → Java/Kotlin (Spring, Quarkus, etc.)
• Gemfile → Ruby (Rails, Sinatra, etc.)
• *.php → PHP (Laravel, Symfony, etc.)

Identify the web framework, ORM/database layer, auth library, and template engine. These determine what patterns to scan for in each OWASP category.

============================================================ PHASE 1: A01 — BROKEN ACCESS CONTROL ============================================================

Scan for access control failures:

AUTH MIDDLEWARE COVERAGE:

• List all route definitions (Express routes, Flask routes, Django urls, etc.)
• Flag routes that handle sensitive data but lack auth middleware
• Flag admin routes accessible without admin/role checks

IDOR (Insecure Direct Object References):

• Find endpoints using user-supplied IDs to fetch resources
• Check if ownership/permission is verified before returning data
• Pattern: findById(req.params.id) without ownership check

PATH TRAVERSAL:

• Find file operations using user input in paths
• Check for ../ sanitization
• Pattern: fs.readFile(userInput), open(user_path)

CORS MISCONFIGURATION:

• Check CORS origin settings — flag * or overly permissive origins
• Verify credentials flag is not combined with wildcard origin

PRIVILEGE ESCALATION:

• Check if role/permission changes require re-authentication
• Verify role checks on mutation endpoints (not just read)

For each finding: file path, line number, severity, description, fix.

============================================================ PHASE 2: A02 — CRYPTOGRAPHIC FAILURES ============================================================

Scan for cryptographic weaknesses:

WEAK ALGORITHMS:

• MD5 used for anything security-related (passwords, tokens, signatures)
• SHA1 used for security (acceptable for checksums only)
• DES, 3DES, RC4, or other deprecated ciphers
• RSA key sizes below 2048 bits
• ECB mode block cipher usage

EXPOSED SECRETS:

• API keys, tokens, passwords hardcoded in source
• Private keys committed to repository
• Connection strings with embedded credentials
• Secrets in client-side/frontend code

WEAK TRANSPORT:

• HTTP URLs for API calls (not HTTPS)
• Missing TLS verification (rejectUnauthorized: false, verify=False)
• Insecure WebSocket connections (ws:// instead of wss://)

DATA EXPOSURE:

• Sensitive data in logs (passwords, tokens, PII)
• Sensitive data in error messages returned to clients
• Sensitive data stored in localStorage/sessionStorage
• Missing encryption for PII at rest

============================================================ PHASE 3: A03 — INJECTION ============================================================

Scan for injection vulnerabilities:

SQL INJECTION:

• String concatenation in SQL queries
• Template literals in SQL without parameterization
• Raw queries with user input: query("SELECT * FROM users WHERE id = " + id)
• Missing prepared statements in database calls

NOSQL INJECTION:

• User input directly in MongoDB/Firestore query operators
• Pattern: { $where: userInput }, { field: { $gt: userInput } }
• JSON.parse on user input used directly in queries

COMMAND INJECTION:

• exec(), spawn(), system() with user-controlled arguments
• Shell commands built with string concatenation
• Missing input sanitization before shell execution

XSS (Cross-Site Scripting):

• innerHTML, dangerouslySetInnerHTML with user data
• Template rendering without auto-escape (| safe, {!! !!}, <%- %>)
• document.write(), eval() with user-controlled strings
• Reflected user input in HTML responses without encoding

LDAP INJECTION:

• User input in LDAP filter strings without escaping

XPATH INJECTION:

• User input in XPath queries without parameterization

For each: exact code location, injection type, proof pattern, fix.

============================================================ PHASE 4: A04 — INSECURE DESIGN ============================================================

Scan for design-level security flaws:

MISSING RATE LIMITING:

• Login/auth endpoints without rate limiting
• Password reset without rate limiting
• API endpoints without throttling
• OTP/verification code endpoints allowing brute force

BUSINESS LOGIC FLAWS:

• Price/quantity manipulation possible via API
• Workflow steps that can be skipped
• Race conditions in concurrent operations (check-then-act)
• Missing server-side validation (client-only checks)

MISSING SECURITY CONTROLS:

• No account lockout after failed attempts
• No CAPTCHA on public-facing forms
• Missing input length limits
• No abuse detection mechanisms

============================================================ PHASE 5: A05 — SECURITY MISCONFIGURATION ============================================================

Scan for configuration issues:

DEBUG/DEVELOPMENT MODE:

• DEBUG=True, NODE_ENV=development in production configs
• Stack traces in error responses
• Verbose error messages exposing internals
• Development tools/routes accessible (e.g., /debug, /swagger unprotected)

DEFAULT CREDENTIALS:

• Default database passwords (postgres, root, admin)
• Default admin accounts
• Default API keys or tokens
• Sample/demo credentials in config files

UNNECESSARY FEATURES:

• Unused endpoints or services exposed
• Directory listing enabled
• Server version headers exposed (X-Powered-By)
• Unnecessary HTTP methods enabled (TRACE, OPTIONS wide open)

MISSING SECURITY HEADERS:

• Content-Security-Policy absent or permissive
• Strict-Transport-Security missing
• X-Frame-Options / X-Content-Type-Options missing
• Referrer-Policy not set
• Permissions-Policy not set

============================================================ PHASE 6: A06 — VULNERABLE AND OUTDATED COMPONENTS ============================================================

Scan for vulnerable dependencies:

DEPENDENCY AUDIT:

• Run the appropriate audit command for the detected package manager
• Parse results grouping by severity
• Check for components with no maintainer or archived repositories
• Flag dependencies more than 2 major versions behind

KNOWN CVE CHECK:

• Cross-reference dependency versions against known CVEs
• Flag any dependency with a Critical or High CVE
• Note if patches or upgrades are available

FRAMEWORK VERSIONS:

• Check if the web framework itself is up to date
• Check runtime version (Node.js, Python, Ruby, etc.)
• Flag end-of-life runtime versions

============================================================ PHASE 7: A07 — IDENTIFICATION AND AUTHENTICATION FAILURES ============================================================

Scan for authentication weaknesses:

PASSWORD POLICIES:

• Check if password strength validation exists
• Minimum length, complexity requirements
• Check for password breach list validation (HaveIBeenPwned integration)

SESSION MANAGEMENT:

• Session token generation (cryptographically random?)
• Session expiration configured
• Session invalidation on logout
• Session fixation prevention (regenerate on login)
• Cookie flags: Secure, HttpOnly, SameSite

MFA:

• Check if MFA is available for sensitive operations
• Verify MFA cannot be bypassed

CREDENTIAL STORAGE:

• Password hashing algorithm (bcrypt/scrypt/argon2 = good; MD5/SHA = bad)
• Salt usage for password hashing
• Iteration count / work factor adequacy

============================================================ PHASE 8: A08 — SOFTWARE AND DATA INTEGRITY FAILURES ============================================================

Scan for integrity issues:

INSECURE DESERIALIZATION:

• JSON.parse() on untrusted input without validation
• pickle.loads(), yaml.load() (unsafe loaders) on user data
• Java ObjectInputStream with untrusted data
• XML external entity (XXE) processing

CI/CD INTEGRITY:

• Unsigned dependencies or plugins
• Missing lock file integrity checks
• Auto-merge without review
• Missing dependency pinning (using latest or *)

UPDATE MECHANISMS:

• Unsigned auto-update payloads
• Missing checksum verification on downloads
• Dependency confusion risk (private package names matching public)

============================================================ PHASE 9: A09 — SECURITY LOGGING AND MONITORING FAILURES ============================================================

Scan for logging deficiencies:

MISSING SECURITY EVENTS:

• Failed login attempts not logged
• Access control failures not logged
• Input validation failures not logged
• High-value transactions not logged

LOG QUALITY:

• Sensitive data in logs (passwords, tokens, PII)
• Missing timestamps or user identifiers in log entries
• Log injection possible (user input in log messages without sanitization)
• Logs not structured (hard to parse/alert on)

MONITORING:

• No alerting configuration found
• No health check endpoints
• No error tracking integration (Sentry, Datadog, etc.)

============================================================ PHASE 10: A10 — SERVER-SIDE REQUEST FORGERY (SSRF) ============================================================

Scan for SSRF vulnerabilities:

URL HANDLING:

• User-supplied URLs passed to HTTP clients without validation
• URL fetching without allowlist/denylist
• Internal service URLs constructable from user input
• Redirect following without origin validation

DNS REBINDING:

• Missing DNS resolution validation
• Time-of-check-to-time-of-use gaps in URL validation

CLOUD METADATA:

• Potential access to cloud metadata endpoints (169.254.169.254)
• Missing network segmentation for internal services
• Internal service discovery exposed to user input

============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================

After producing the security analysis, validate thoroughness:

1. Verify every category in the audit was actually checked (not skipped).
2. Verify every finding has a specific file:line location.
3. Verify severity ratings are justified by impact assessment.
4. Verify no false positives by re-reading flagged code in context.

IF VALIDATION FAILS:

• Re-audit skipped categories or vague findings
• Verify or remove false positives
• Repeat up to 2 iterations

============================================================ OUTPUT ============================================================

OWASP Top 10 Audit Report

Project: [name] Stack: [detected technologies] Date: [date]

Summary

Detailed Findings

For each category with WARN or FAIL:

#### [Category Name]

Risk Assessment

• Critical findings: N (must fix immediately)
• High findings: N (fix before next release)
• Medium findings: N (plan to address)
• Low findings: N (track and review)

Remediation Priority

[Ordered list of fixes by severity and effort, Critical first]

============================================================ NEXT STEPS ============================================================

After reviewing the audit:

• "Run /pentest to verify exploitability of injection and auth findings."
• "Run /dependency-scan to auto-fix vulnerable components (A06)."
• "Run /encryption to address cryptographic failures (A02)."
• "Run /secure for the full security posture assessment."

============================================================ SELF-EVOLUTION TELEMETRY ============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /owasp — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT ============================================================

• Do NOT modify any code — this is an audit skill, not a fix skill.
• Do NOT run actual exploits or attacks against the application.
• Do NOT expose discovered secrets in the output — redact them (show first 4 chars + ***).
• Do NOT skip categories — audit all 10 even if some seem irrelevant.
• Do NOT mark a category as PASS without actually scanning for it.
• Do NOT conflate suspicion with confirmed findings — note confidence level.
• Do NOT install external scanning tools — analyze code directly.