Security check

Audit the target for OWASP-class vulnerabilities and report each finding with severity, exact location, exploit path, and a concrete fix. This is a read-only review: never edit, stage, or run application code.

Scope — resolve $ARGUMENTS in this order, first match wins

1. Empty: review the current uncommitted change. Run git diff HEAD for tracked edits; run git status --porcelain to list untracked files, then read the contents of each with a file read (status only names them, it does not show their code). If the tree is clean, review the last commit with git show HEAD.
2. Exactly diff: review the working-tree diff via git diff HEAD plus untracked files as in step 1.
3. Points at an existing file or directory (test with a filesystem check): review that file or directory tree, even if the name also matches a branch. A path always wins the tie over a git ref.
4. Otherwise treat as a git ref or range: a single ref (HEAD~2, abc1234, main) → review git show <ref>; a range (main..HEAD, HEAD~3..HEAD) → review git diff <range>. To review a branch as a path instead, pass ./name.

Method

1. Detect the stack and conventions first: read manifest files (package.json, requirements.txt, go.mod, pom.xml, Gemfile, composer.json), the ORM/query layer, the web framework, and the auth/session middleware. Anchor every check to what this project actually uses.
2. Trace untrusted input to dangerous sinks. Sources: HTTP params/body/headers/cookies, path/query strings, uploaded files, env, external APIs, message queues, DB reads that echo user data. Follow each to sinks and flag when it reaches one unsanitized.
3. Check each vulnerability class against the code:
   • Injection: string-built SQL/NoSQL, exec/system/eval/child_process, template injection, LDAP/XPath. Require parameterized queries and argument arrays, not concatenation or shell strings.
   • XSS: unescaped output, dangerouslySetInnerHTML, innerHTML, v-html, |safe, disabled auto-escaping, reflected/stored user data.
   • Broken access control: endpoints/handlers missing authz checks, IDOR (object IDs from the request used without an ownership check), missing tenant scoping, client-side-only gating, mass assignment / unfiltered object binding.
   • Secrets: hardcoded keys, tokens, passwords, connection strings, private keys; secrets logged or in error responses; credentials committed in config or fixtures. Verify against real high-entropy values, not placeholders.
   • Unsafe deserialization: pickle, yaml.load, native/PHP unserialize, Java readObject, JS prototype pollution on untrusted input.
   • SSRF: server-side fetch/HTTP/URL open with a user-controlled host, no allowlist, cloud-metadata (169.254.169.254) reachable.
   • Path traversal / file ops: user input in file paths, unvalidated upload names/types, archive extraction (zip slip), missing canonicalization.
   • Crypto: MD5/SHA1 for passwords or signatures, ECB, static/predictable IV or salt, hardcoded keys, Math.random for tokens, missing password hashing (bcrypt/argon2/scrypt), disabled TLS verification.
   • Missing controls: no rate limiting / lockout on auth, OTP, or costly endpoints; missing CSRF protection on state-changing routes; permissive CORS (* with credentials); missing security headers where the framework expects them.
   • Sensitive-data exposure: PII/tokens in logs, verbose stack traces to clients, secrets in URLs, overly broad API responses.
4. Confirm each hit by reading surrounding code — rule out existing sanitizers, prepared statements, framework auto-escaping, or middleware that already mitigates it before reporting.

Output

Group findings by severity (Critical, High, Medium, Low). For each:

• Title — vulnerability class and one-line summary.
• Location — file:line.
• Exploit — the specific input and steps an attacker uses to trigger it.
• Fix — the concrete change (name the safe API/function/pattern for this stack), with a minimal corrected snippet.

End with a one-line summary count per severity. If nothing is found in a class you checked, say so briefly rather than padding.

Rules

• Never modify files or run application/build/test commands; only git read commands and file reads.
• Always cite an exact line and a realistic exploit — no theoretical "could be unsafe" without a path.
• Rank by exploitability and blast radius, not by how easy the finding was to spot.
• Prefer flagging a real risk over staying silent; when unsure, report it and state the assumption. Do not invent issues to fill a quota.
• Judge against this project's conventions and trust boundaries, not a generic checklist.