Vulnerability Scanner

---
name: vulnerability-scanner
description: OWASP Top 10 aligned security scanner for any web application or API, in any language or framework. Use whenever the user wants a standardized OWASP-based scan, mentions "OWASP", "Top 10", "security scan", "pentest checklist", or wants findings organized against the official ten categories with consistent severity ratings — a strong complement to code-audit for producing a compliance-style, auditable result.
---

# Vulnerability Scanner — OWASP Top 10 Assessment

A defensive skill that walks any project against the official OWASP Top 10 (2021/latest), category by category, producing a consistent and repeatable assessment.

## When to use this
- Explicit request for an OWASP Top 10 scan
- Full security assessment before a launch
- Need for a standardized, compliance-style report for stakeholders or clients

## The Ten Categories and What to Check

1. **Broken Access Control** — Does every endpoint enforce authorization? Can a user reach another user's resources by changing an ID?
2. **Cryptographic Failures** — Sensitive data transmitted or stored without encryption (HTTP instead of HTTPS, plaintext PII), outdated algorithms.
3. **Injection** — SQL/NoSQL/Command/Template injection; check every point where user input reaches a query, command, or interpreter.
4. **Insecure Design** — Missing logical safeguards (no rate limit on login, no ownership check before bulk delete, business logic that assumes good faith) — flaws in the design itself, not just the implementation.
5. **Security Misconfiguration** — Unsafe defaults, verbose error messages leaking stack traces, wide-open CORS (`*`) combined with credentials.
6. **Vulnerable and Outdated Components** — Hand off to `dependency-security` for a full CVE-based scan.
7. **Identification and Authentication Failures** — Weak password policies allowed, no MFA on sensitive accounts, session management flaws.
8. **Software and Data Integrity Failures** — Unsigned/unverified updates or dependencies, unsafe deserialization of untrusted data, CI/CD pipelines without integrity checks.
9. **Security Logging and Monitoring Failures** — Are failed login attempts logged? Is there alerting on suspicious activity? Are logs stored securely (no secrets/PII in plaintext logs)?
10. **SSRF (Server-Side Request Forgery)** — Any code that fetches a URL supplied by user input (`fetch(userProvidedUrl)`) without an allow-list?

## Mandatory Report Format Per Finding

```
Vulnerability: [name and OWASP category number]
Severity: Critical | High | Medium | Low
Location: [file and line]
Impact: [concrete business/user impact]
Proof: [evidence from the code, never assumption]
Fix: [specific remediation steps]
```

## Methodology
1. Walk through all ten categories in order for every project, even if some don't apply — state that explicitly ("N/A — no file uploads present in this project").
2. Don't duplicate a finding already surfaced by `code-audit` under a different label; instead cross-reference the appropriate category number.
3. Attach a short (one to two sentence) realistic exploitation scenario to each finding to convey impact — without writing an actual working exploit payload.

## After the Scan
- Produce a **Security Score out of 100** (see scoring methodology in `security-reporting`).
- Hand off to `remediation-engine` if the user wants fixes applied directly.
- Hand off to `security-reporting` for a polished final report.

## Rules
- The sole purpose is improving the security of the user's own project; do not provide detailed, ready-to-use attack instructions against third-party systems.
- Minimize false positives — every finding must be grounded in an actual line of code, not a generic guess.