# Owasp

> Systematic audit against the OWASP 2021 Top 10 web application security risks with severity-rated, file-level findings.

- Skill: `tinh2/owasp-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tinh2/owasp-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tinh2/owasp-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: tinh2 (https://skillmd.com/u/tinh2)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/tinh2/owasp-2

---


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

| ID  | Category                          | Status | Findings |
|-----|-----------------------------------|--------|----------|
| A01 | Broken Access Control             | [PASS/WARN/FAIL] | N |
| A02 | Cryptographic Failures            | [PASS/WARN/FAIL] | N |
| A03 | Injection                         | [PASS/WARN/FAIL] | N |
| A04 | Insecure Design                   | [PASS/WARN/FAIL] | N |
| A05 | Security Misconfiguration         | [PASS/WARN/FAIL] | N |
| A06 | Vulnerable Components             | [PASS/WARN/FAIL] | N |
| A07 | Auth Failures                     | [PASS/WARN/FAIL] | N |
| A08 | Data Integrity Failures           | [PASS/WARN/FAIL] | N |
| A09 | Logging Failures                  | [PASS/WARN/FAIL] | N |
| A10 | SSRF                              | [PASS/WARN/FAIL] | N |

### Detailed Findings

For each category with WARN or FAIL:

#### [Category Name]

| # | Severity | File | Line | Description | Fix |
|---|----------|------|------|-------------|-----|
| 1 | Critical | path/to/file.ts | 42 | Description | Recommended fix |

### 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.