Vulnerability scanner

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.