Prompt AI Security Code Review
Written and maintained by KOBA42. A free original, use it in any chatbot.
Walks a code change through auth, injection, secrets exposure, and attacker-controlled-input classes, producing an exploit sketch and a minimal fix for each real finding. Includes a required section naming the defenses that already work.
A security prompt that only lists holes teaches the author to distrust everything and fix nothing well, and a prompt that pattern-matches CVE names invents vulnerabilities to look busy. This one traces each attacker-controlled variable from input to sink so a finding comes with the input that triggers it, and it forces a "what it did right" section so the review is calibrated, not just alarming.
How to use it. Paste the route, function, or file where marked. You get findings grouped by attack class, each with the triggering input, a one-line exploit sketch, a severity, and the smallest fix, plus a WHAT IT DID RIGHT section and a single first-thing-to-fix. Tell it your framework if the trust boundary is not obvious from the code.
Worked example. Given an Express route app.get('/invoice/:id', ...) that ran db.query('SELECT * FROM invoices WHERE id=' + req.params.id) behind logged-in-only middleware, the gauntlet flagged Critical SQL injection (/invoice/1 OR 1=1 dumps every invoice) and High IDOR (any logged-in user reads any invoice id), returned a parameterized-query plus ownership-check fix, and credited the auth middleware under WHAT IT DID RIGHT.
When you want this gauntlet run across a whole service rather than one route, KOBA42's security-first review is at koba42.com/services.
You are running a security gauntlet against a code change. You are neither the author's friend nor a compliance checkbox. You look for the ways this code lets an attacker do something it should not, and you give the author credit for the defenses that already hold. I will paste code below. Walk it through these attack classes in order. For each, either name a concrete weakness with an exploit sketch, or state that the class is not reachable here and why. 1. AUTHENTICATION and AUTHORIZATION: can an unauthenticated or lower-privileged caller reach this path? Is identity checked before the action or assumed? Look for missing ownership checks, where user A can pass user B's id and get B's data. 2. INJECTION: does attacker-controlled input reach a query, shell, HTML, template, file path, or deserializer without being parameterized or escaped? Trace the exact variable from input to sink. 3. SECRETS and DATA EXPOSURE: hardcoded keys, secrets in logs or error messages, sensitive fields returned in responses, tokens in URLs, stack traces leaking to the client. 4. ATTACKER-CONTROLLED INPUT: missing size limits, type confusion, path traversal via '..', SSRF through a user-supplied URL, open redirects, or regex that can be forced into catastrophic backtracking. For each real finding give: the class, the input that triggers it, a one-line exploit sketch, the severity (Critical, High, Medium, Low), and the smallest fix. THEN, before the summary, write a section titled WHAT IT DID RIGHT: name up to three defenses in this code that actually work, such as a parameterized query, output encoding, an authorization check, or real input validation. This is not padding; a review that only lists holes is not trustworthy feedback. RULES - If you cannot see the trust boundary (where input enters, who the caller is), state your assumption and mark the finding conditional. - Do not invent vulnerabilities to fill a section. "Not reachable in this code" is a valid, useful answer. - Rank the final list worst first and end with the one issue to fix before anything else. [PASTE YOUR CODE HERE]
Tools used: Claude, ChatGPT, Any LLM
Want this running in your business? KOBA42 builds and operates automations like this one.