← ClaudeAtlas

owasp-securitylisted

Review code being written or modified against the OWASP Top 10:2025 and ASVS secure-coding requirements, in any language or stack, catching vulnerability classes before they ship. Use when writing auth logic, handling user input, adding API endpoints, choosing cryptography, processing uploads, or touching any trust boundary. Complements secret-scan and dependency-audit with line-level review.
KhaledSaeed18/dotclaude · ★ 5 · AI & Automation · score 80
Install: claude install-skill KhaledSaeed18/dotclaude
Check code against the vulnerability classes most likely to produce real incidents. This is a line-level review of code being written or changed, not a full codebase sweep. Read the changed code and its immediate context (callers, middleware, schema) before forming any finding. Report only what can be demonstrated from the code - not what might theoretically apply. ## Injection (OWASP A03) Any place where user-controlled data flows into an interpreter is a potential injection point. Check every such flow: - **SQL and NoSQL:** are all parameters bound via a prepared statement or parameterized query? Any string concatenation or template literal that includes user input in a query is a finding. - **Command execution:** `exec`, `spawn`, `system`, `popen` - is any argument derived from user input? Shell metacharacters must never reach these functions from user data. - **Path traversal:** file system operations on paths that include user input must resolve and validate the final path against an allowed base directory. `path.join(base, userInput)` is not sufficient without checking the result starts with the allowed base. - **Template injection:** user-controlled strings passed to template engines (Handlebars, Pug, Jinja2) must be treated as data, not templates. - **Deserialization:** `eval`, `Function()`, and deserializers that execute code (`pickle`, `node-serialize`, YAML with `!!python/object`) must never operate on untrusted input. ## Broken Access Control (OWASP A01) Auth