AI Code Review Checklist for XSS and Secrets

A recent study found that 62% of AI-generated code solutions contain design flaws or known security vulnerabilities, according to the Cloud Security Alliance. That number should stop any team shipping code from Copilot, Cursor, or Claude without a second look. Vibe coding has made it easy to generate working features in minutes, but "working" and "safe" are not the same thing.

This piece is a practical checklist for reviewing AI-generated code, with a specific focus on two problem areas: cross-site scripting and hardcoded secrets. These two bug classes show up constantly in AI output, and both are easy to miss if you are reviewing code for function rather than security.

The goal here is not to scare anyone off using AI tools. It's to give reviewers, team leads, and solo developers a concrete process for catching the mistakes that AI coding assistants make most often.

#Why AI Generated Code Needs a Different Review Process

Human-written code usually comes with context. A developer who writes a function knows why it exists, what data flows through it, and where the risk lies. AI-generated code often lacks that inline commentary and rationale, according to Wiz, which creates a context gap that slows down manual security review.

That gap matters because reviewers end up reverse-engineering intent before they can even evaluate risk. Add in the sheer volume of code AI assistants produce, and you get a review bottleneck that most teams are not prepared for.

Cycode has pointed out that AI coding assistants generate code at high velocity, but developers frequently accept suggestions without close examination. That acceptance pattern bypasses the governance controls that would normally catch a risky pattern before it reaches production.

None of this means AI-generated code is fundamentally different from human code at the vulnerability level. DerSecur notes that AI output needs the same kind of security review as anything a person writes, just applied more often and at greater scale. SQL injection, broken auth, and insecure deserialization do not disappear just because a model wrote the line.

The practical takeaway: AI generated code security review is not a new discipline. It is the same discipline, run more frequently, against more code, with less built-in context.

#XSS Vulnerabilities in AI-Generated Code

Cross-site scripting keeps showing up in AI output for a predictable reason: language models are trained to produce code that works, not code that sanitizes input by default. A chatbot asked to "display the user's comment on the page" will often hand back something that renders raw HTML.

#Common Patterns to Watch For

Here are the XSS patterns that show up most often in AI-suggested code:

• Direct DOM injection: Using innerHTML, outerHTML, or document.write() with unsanitized user input instead of textContent or safe templating.
• Unescaped template output: Server-side templates that interpolate user data directly into HTML without an escaping filter.
• Trusting client-side validation only: Code that checks input format in the browser but skips server-side validation entirely.
• React's dangerouslySetInnerHTML: AI assistants suggest this prop more often than you'd expect, usually because it's the fastest way to render formatted text.
• Missing Content Security Policy headers: AI-generated boilerplate for new apps rarely includes CSP configuration unless explicitly prompted.

#A Quick Example

Here's a pattern that shows up frequently when asking an AI assistant to build a simple comment display feature:

// Vulnerable pattern AI assistants commonly produce
function displayComment(comment) {
  document.getElementById('comments').innerHTML += 
    `<div class="comment">${comment.text}</div>`;
}

The fix is straightforward once you know to look for it:

// Safer alternative
function displayComment(comment) {
  const div = document.createElement('div');
  div.className = 'comment';
  div.textContent = comment.text;
  document.getElementById('comments').appendChild(div);
}

The vulnerable version isn't wrong in any obvious way. It runs, it displays the comment, and a developer skimming for logic errors will likely approve it. That's exactly the problem with vibe coding vulnerabilities: they pass functional review and fail security review, and most teams only do the first one.

#Secrets Exposure: Why AI Assistants Leak Credentials

Hardcoded secrets are the other repeat offender. AI assistants trained on public code repositories have seen millions of examples of API keys, database connection strings, and auth tokens embedded directly in source files, often because that's how tutorials and quick-start guides are written.

When you ask an AI tool to "connect to the database" or "add Stripe payment processing," it frequently generates a working example with a placeholder credential sitting right in the function. The intent is harmless. The outcome, if nobody replaces that placeholder before committing, is a leaked secret in your git history.

#What This Looks Like in Practice

A typical AI-generated database connection might look like this:

# Common AI-suggested pattern
import psycopg2
conn = psycopg2.connect("postgresql://USER:PASSWORD@example.internal:5432/DATABASE")

The model isn't malicious, it's just demonstrating the pattern the way it was trained. The fix is to move credentials into environment variables immediately, before the code is ever committed:

import os
import psycopg2

conn = psycopg2.connect(
    host=os.environ["DB_HOST"],
    user=os.environ["DB_USER"],
    password=os.environ["DB_PASSWORD"],
    dbname=os.environ["DB_NAME"]
)

#Where AI-Generated Secrets Tend to Hide

Reviewers should check these spots specifically, since they are easy to overlook in a normal pull request scan:

• Test and seed files: AI assistants often generate sample data with "realistic" looking API keys for test fixtures.
• Configuration file templates: .env.example files that accidentally contain a real value instead of a placeholder.
• Inline comments: Suggestions that include a commented-out working credential "for reference."
• CI/CD YAML files: Pipeline configs that hardcode a token instead of referencing a secrets manager.
• Docker and docker-compose files: Environment blocks with literal values instead of variable references.

Safeguard.sh has noted that dependency-checking tools can evaluate packages against live registry data at the point they're fetched, which catches a different but related risk: AI assistants sometimes suggest packages that don't exist, or typosquatted versions of popular libraries. That's worth checking alongside your secrets scan, not instead of it.

#Building Your AI Code Audit Checklist

A workable AI code audit checklist needs to be short enough that developers actually use it, but specific enough to catch the patterns above. Here's a version built around XSS and secrets specifically.

This list is deliberately narrow. It's built to run fast, as a first pass, before a deeper manual or automated review for other vulnerability classes like SQL injection or broken access control.

Each check type targets a different failure mode, and skipping any one of them leaves a gap AI-generated code is likely to fill.

#Automation vs. Manual Review: When to Use Each

Automated tooling and human review solve different parts of this problem, and neither one replaces the other.

Static analysis (SAST) and reachability engines are good at flagging specific CWE classes. Safeguard.sh notes that these tools can catch CWE-89 (SQL injection), CWE-798 (hardcoded credentials), and CWE-502 (insecure deserialization) at the elevated rates AI assistants tend to produce them. That's the right tool for high-volume, repeatable pattern matching.

Manual review, or a second AI reviewer, is better suited to design-level questions. Endor Labs has described setups where multiple AI agents review pull requests specifically for design flaws and architectural changes, things like new API endpoints that change the security posture of the whole application. A static scanner won't catch "this new endpoint exposes an internal admin function without a role check." A human or a reasoning-focused reviewer will.

The practical split looks like this:

• Use automation for: secrets detection, known vulnerable patterns, dependency checks, and anything with a clear signature.
• Use manual or AI-agent review for: architectural changes, new trust boundaries, authentication flow changes, and anything where intent matters more than syntax.

Veracode has pointed to real-time IDE integration as a practical middle ground, where a developer gets security feedback on AI-generated suggestions the moment they're accepted, rather than waiting for a pull request review days later. Catching an XSS pattern at the point of suggestion is far cheaper than catching it in a security audit three sprints later.

#Governance: Restricting AI Use for Security-Critical Code

Not every part of a codebase should accept AI-generated suggestions without extra scrutiny. Veracode's guidance on this is direct: organizations should build AI governance policies that include mandatory security review for AI-generated code, plus explicit restrictions on using AI assistants for security-critical components.

In practice, that means drawing a line around specific areas:

• Authentication and session management logic
• Payment processing and financial transaction code
• Access control and permission systems
• Cryptographic implementations
• Direct database query construction

Code in these areas should either avoid AI generation entirely or require a mandatory senior review plus automated scanning before merge, no exceptions. This isn't about distrust of the tools. It's about matching the level of scrutiny to the blast radius if something goes wrong.

#Frequently Asked Questions

A: The vulnerability classes are the same, but the volume and speed are different. You need the same checks, run more consistently, because AI output is produced and accepted faster than a human typically writes and self-reviews code.

A: Start with hardcoded secrets and XSS, since both are common in AI output and both are catchable with fast, specific checks. From there, move to SQL injection and insecure deserialization, which show up at elevated rates across AI models according to industry analysis.

A: Yes, for pattern-based detection and even some architectural review, as seen in multi-agent review setups. But AI review should supplement, not replace, scanning tools and human sign-off on security-critical changes.

A: Bake the checks into CI/CD so they run automatically on every pull request. A secrets scanner and a basic XSS pattern grep can run as required status checks, which removes the option to skip them entirely.

#Takeaways

Reviewing AI-generated code is not optional busywork, it's a direct response to a documented failure rate. Here's what to act on this week:

• Add a secrets scanner as a required CI check if you don't already have one.
• Grep recent AI-assisted pull requests for innerHTML, dangerouslySetInnerHTML, and raw string concatenation into HTML.
• Mark your security-critical code paths and require manual review there regardless of how the code was generated.
• Give your team the nine-item checklist above and make it part of the pull request template, not a separate document nobody opens.

The models will keep improving, but the patterns in this piece are stable enough to build process around right now.