Trace untrusted input to dangerous sinks — where attacker-controlled data becomes a query, a command, markup, a request, or a file path.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: follow untrusted input from where it enters to where it does something dangerous, and find the places it reaches a sink without being parameterized, escaped, or validated.
Read-only pass. Trace data flow through the code; change nothing. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
string-built queries; unparameterized input reaching the database
shell-outs, eval, and deserialization of untrusted data
unescaped input rendered to HTML/DOM; unsafe innerHTML/dangerouslySetInnerHTML
user-supplied URLs fetched by the server
traversal, unrestricted upload type/size, unsafe filenames
user input into template engines or expression evaluators
where validation should sit (server) versus where it actually sits (client)
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List untrusted sources.
Give the source → sink path and file:line for every finding.
Rank by reachability × impact.
Create INJECTION.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:input-injection-audit.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-input-injection-audit:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=83 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/83.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Input & Injection Audit You are working inside this repo. Mission: follow untrusted input from where it enters to where it does something dangerous, and find the places it reaches a sink without being parameterized, escaped, or validated. Read-only pass. Trace data flow through the code; change nothing. Your only write is the report file. ## Phase 1 — Map sources and sinks - List untrusted sources: request params, bodies, headers, webhooks, uploads, queue messages, third-party responses. - List dangerous sinks: the database, the shell, HTML/DOM, outbound requests, the filesystem, template engines. - Sketch which sources can reach which sinks; those paths are the audit. ## Phase 2 — Audit through 7 lenses Give the source → sink path and file:line for every finding. 1. **SQL / NoSQL injection** — string-built queries; unparameterized input reaching the database 2. **Command & code injection** — shell-outs, `eval`, and deserialization of untrusted data 3. **Cross-site scripting** — unescaped input rendered to HTML/DOM; unsafe `innerHTML`/`dangerouslySetInnerHTML` 4. **Server-side request forgery** — user-supplied URLs fetched by the server 5. **Path & file handling** — traversal, unrestricted upload type/size, unsafe filenames 6. **Template & expression injection** — user input into template engines or expression evaluators 7. **Validation boundary** — where validation should sit (server) versus where it actually sits (client) ## Phase 3 — Curate - Rank by reachability × impact: a path an anonymous caller can trigger outranks an admin-only one. - For each finding, state the fix in the right layer — parameterize, escape at output, allow-list, or sandbox. - Note systemic causes: one unsafe helper reused everywhere beats fixing call sites one by one. ## Phase 4 — Report Create `INJECTION.md` at repo root: 1. **Reachability summary** — findings by severity and who can trigger them 2. **Findings** — each: severity S1–S3 · source → sink path · proof of reach · the layer-correct fix 3. **Systemic fixes** — the shared helpers or patterns that would close whole classes at once 4. **Validation strategy** — where trust boundaries should be drawn going forward Start the report with today's date. If `INJECTION.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Follow the data; a sink is only a bug if untrusted input reaches it - Fix at the right layer — escaping output beats sanitizing input beats hoping - No untrusted input in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which injection paths to close first
reports/ directory exists at the repo root, write the report there instead of the root.A defensive review of your own codebase — auth gaps, injection surfaces, exposed secrets, and data leaks, ranked by exploitability.
Vulnerable, abandoned, oversized, or duplicated packages — the full health check on every dependency this project stands on, with removal candidates named.
Keyboard navigation, contrast, labels, and screen-reader flow — audited end-to-end along the core user journey.
Hardcoded strings, locale-blind number and date formatting, and layouts that break in translation — every gap between you and a non-default-locale user.
Runs inside these playbooks — curated sequences you can launch with one paste: