Security and Risks with AI-Generated Code

The Security Problem

AI-generated code can reproduce insecure patterns, omit controls, misunderstand a framework, or use outdated APIs. A polished response is not evidence that the implementation is secure.

Common Vulnerabilities in AI Code

These are common web-application risks worth checking in AI-generated code. The relevant risks depend on the system, data, trust boundaries, and deployment environment.

SQL Injection: A Real Example

SQL injection is a critical risk when untrusted input is combined with a query string, and the vulnerable code can look superficially reasonable.

// DANGEROUS — AI-generated, vulnerable to SQL injection

app.get('/api/activities', (req, res) => {

  const member = req.query.member;

  const query = `SELECT * FROM activities WHERE member = '${member}'`;

  db.query(query, (err, results) => {

    res.json(results);

  });

});

// SAFER FOR VALUE INPUT — uses parameter binding
app.get('/api/activities', (req, res) => {

  const member = req.query.member;

  const query = 'SELECT * FROM activities WHERE member = ?';

  db.query(query, [member], (err, results) => {

    res.json(results);

  });

});

Use the parameter-binding mechanism documented by your database driver and apply least-privilege permissions. In this example, ? is a value placeholder for drivers that support that syntax; identifiers and dynamic query structure require separate allow-listing or safe query-building APIs.

AI Hallucinations

Beyond security vulnerabilities, AI has a broader reliability problem: hallucinations. AI can generate code that references packages that don't exist, uses API methods that were never implemented, or follows patterns from outdated documentation.

The Security Review Prompt

AI can supplement a security review by suggesting issues to investigate. It does not replace threat modeling, tested controls, dependency analysis, security tooling, or review by someone with the required expertise.

Review this code for security vulnerabilities.



[paste your code]



Check specifically for:

- SQL injection (string interpolation in queries)

- XSS (unescaped user input in HTML)

- Hardcoded secrets (API keys, passwords, tokens)

- Missing input validation and sanitization

- Authentication/authorization bypasses

- Insecure data storage (plain-text passwords)

- Missing CORS configuration

- Missing rate limiting on sensitive endpoints

- Insecure HTTP headers



For each issue found:

- Describe the vulnerability

- Explain how it could be exploited

- Show the fix

Use a prompt like this as one review input for code that crosses trust boundaries. Verify every finding and every claimed absence with tests, tools, official guidance, and system context.

Data Privacy Risks

When you paste code into AI for review or generation, you're sharing that code with a third-party service. This creates data privacy considerations that every developer needs to understand.

Scan code, diffs, logs, and stack traces before sending them to an AI service. Remove secrets and minimize personal, customer, and internal infrastructure data. Store real secrets through the application's approved secret-management path, not as values to paste back into source code.

The Security Checklist

Use this checklist on every project that handles user data, authentication, or external APIs. Ask AI to verify each item — and verify AI's answers yourself for critical systems.

Building Secure Code with AI

Include security requirements in the initial task, then verify the implementation with threat modeling, tests, supported tooling, and review. Prompt constraints are one input, not a security control by themselves.

The values below are example constraints, not universal defaults. Replace them with the application's threat model, authentication policy, framework guidance, and measured limits.

Build an Express.js login endpoint.


Security requirements:

- Hash passwords with Argon2id using parameters selected from current OWASP guidance
- Use the application's established session design; document expiration, rotation, revocation, storage, and CSRF controls
- Apply the project's tested login-abuse controls; state the thresholds and denial-of-service trade-offs
- Enforce the current authentication policy for identifiers and password length
- Return generic error messages (don't reveal if email exists)

- Log failed attempts server-side

- Set secure HTTP headers (helmet)



Do NOT:

- Store passwords in plain text

- Include secrets in the code (use process.env)

- Return stack traces on error

Explicit requirements make omissions easier to notice, but the model can still violate or misunderstand them. Treat every generated control as untrusted until it has been checked in the actual framework and deployment context.

Over-Reliance: The Biggest Risk

The security threats above are technical. But the most dangerous risk of AI-generated code is human, not technical: over-reliance.

When code appears instantly and looks correct, there's a strong psychological tendency to trust it without verification. This is especially dangerous because AI-generated code looks professional — it's well-formatted, uses proper naming conventions, and includes comments. All of this creates a false sense of security.

Current Security References

Security guidance changes. For high-consequence decisions, start with current primary guidance and the documentation for the exact framework, runtime, and database version you use. This chapter was checked on Aug 28 2026 against:

• OWASP Top 10:2025 — current web-application risk categories, including broken access control and software supply-chain failures
• OWASP Password Storage Cheat Sheet — Argon2id guidance and bcrypt's legacy role
• OWASP REST Security Cheat Sheet — token, transport, validation, and CORS guidance

Related Guides