AI Security Auditing, Part 4: Find Injection, XSS & SSRF With AI

AI Security Auditing series — Part 4 of 5. Part 1: Setup · Part 2: Authentication · Part 3: API & OWASP · Part 4: Injection & XSS · Part 5: Runtime detections

Injection is the oldest bug in the book and still one of the most damaging. It's what happens when data your app was supposed to store or display gets executed instead. In this part we audit for the whole injection family — server-side and client-side — with an AI agent.

New here? Start with Part 1.

Why AI is good at finding injection

Injection is a source-to-sink problem: untrusted input (the source) reaches a dangerous operation (the sink) without being neutralized in between. Classic sinks:

• A raw SQL string built with user input → SQL injection.
• A shell command built with user input → command injection.
• A template rendered with user input → server-side template injection (SSTI).
• A file path built with user input → path traversal.
• Unescaped output into HTML → cross-site scripting (XSS).
• A user-supplied URL the server fetches → server-side request forgery (SSRF).

Tracing those paths across every handler is exactly the kind of consistent, exhaustive work AI reviewers do well — and where human reviewers, reading the hundredth route, start skimming.

Run the server-side injection audit

Go to /threat-modeling/injection and click Copy prompt. It maps to OWASP A03 (Injection) and CWE-89/78/94 (SQLi / command injection / code injection). Paste it into your agent at the project root, then open threat/injection/injection-code-findings.html.

Typical findings:

• String-concatenated SQL — db/reports.js:53, critical. `SELECT * FROM orders WHERE id = ${req.query.id}` — a textbook SQLi. Fix: parameterized query.
• child_process.exec with user input — services/convert.js:19, critical. A filename flows into a shell command. Fix: execFile with an argument array, and validate the input.
• Template rendered from user data — views/render.js:31, high. SSTI can escalate to remote code execution.
• Path built from req.params — routes/files.js:22, high. ../../etc/passwd territory. Fix: resolve and confine to a base directory.

Run the client-side audit (XSS / CSRF / CORS)

Server-side injection has a client-side sibling. Go to /threat-modeling/xss-csrf-cors and copy that prompt too. It maps to A03 / A05 / A07 and covers:

• XSS — unescaped user data rendered into the DOM, dangerouslySetInnerHTML, missing output encoding, and a weak or absent Content-Security-Policy.
• CSRF — state-changing routes that accept requests without a token or SameSite protection.
• CORS — Access-Control-Allow-Origin: * combined with credentials, or a reflected-origin misconfiguration that trusts any site.

Open threat/xss-csrf-cors/xss-csrf-cors-code-findings.html and triage the same way — criticals first.

SSRF deserves its own attention

SSRF (OWASP API7) is increasingly the most dangerous of the group in cloud environments, because a server tricked into fetching an internal URL can often reach the cloud metadata endpoint and steal credentials. The injection and API audits both flag SSRF sinks — any place a user-controlled URL is fetched. The fix is an allowlist of permitted hosts plus blocking requests to internal/link-local ranges. For the cloud-credential angle, also run /threat-modeling/secrets-and-cloud-iam.

Code fixes close holes; detection catches attempts

Injection is the clearest case in this whole series where you want both layers, because injection attacks are loud. Attackers probe: they send ' OR 1=1--, <script>, ../, and http://169.254.169.254/ across your endpoints looking for one that bites.

That means runtime detection isn't just a safety net — it's an early-warning system. Open injection-code-findings's companion, injection-detection-mitigation.html, for rules that flag injection-shaped payloads in live traffic. Crucially, SecureNow can block these inline at the firewall in seconds, so a probing attacker gets a 403 on the endpoint you haven't patched yet, not a stack trace.

Checklist before you move on

• Ran the injection prompt; fixed all string-built queries and shell commands
• Ran the XSS/CSRF/CORS prompt; tightened CSP and output encoding
• Reviewed every SSRF sink and added a host allowlist
• Skimmed the detection-mitigation reports for inline-blocking rules
• Committed the reports to version control

Next

You've now found the vulnerabilities in three of the highest-risk categories. The final part is what makes the whole effort permanent: turning every detection-mitigation report into an always-on rule that catches attacks in production.

Continue to Part 5 — Turn AI findings into runtime detections →