The Hidden Security Risks in AI-Generated Code

AI coding tools are trained on millions of code repositories. That includes a lot of excellent, well-secured code. It also includes a staggering amount of code with security vulnerabilities that have been copied, forked, and replicated across the internet for years.

When you ask an AI to build you a login system, a database query, or a file upload feature, it draws from all of that training data. The result usually works. It also frequently contains security holes that a professional developer would catch immediately but a non-technical founder would never notice.

This is not about being paranoid. It is about knowing what to check. Here are the specific vulnerabilities that show up most often in AI-generated code, and what each one actually means for your business.

SQL Injection: The Classic That Never Dies

SQL injection has been the number one web application vulnerability for over two decades, and AI tools still generate code vulnerable to it on a regular basis.

Here is what it looks like. You ask AI to build a search feature. It generates something like a database query that directly inserts user input into the SQL string. If someone types a normal search term, it works fine. If someone types a specially crafted string, they can read your entire database, delete tables, or extract every customer record you have.

The fix is parameterised queries, where user input is treated as data rather than executable code. It is a well-known pattern. AI tools know about it. But they do not consistently apply it, especially in quick prototyping scenarios where the emphasis is on getting something working fast.

Hardcoded Secrets

This one is epidemic in AI-generated code. API keys, database passwords, encryption secrets, and third-party service credentials embedded directly in source files.

AI tools do this because it makes the code “work” in the simplest way possible. The code runs, the API call succeeds, the demo looks great. But those secrets are now sitting in your codebase, potentially committed to version control, and accessible to anyone with read access to the repository.

If your code is in a private GitHub repo, you might think this is fine. It is not. GitHub credentials get leaked. Laptops get stolen. Employees leave. Contractors have access they should not have. The principle of least privilege exists for a reason: secrets belong in environment variables or a dedicated secrets manager, never in source code.

Missing Input Validation

AI-generated code tends to trust user input implicitly. Whatever the user submits, the app accepts and processes. This creates problems ranging from annoying to catastrophic.

On the mild end: a user submits a form with an email field and types “not an email.” Your app stores it, your email system chokes on it later, and you have corrupted data in your database.

On the severe end: a user submits a file upload and sends a PHP script instead of a JPEG. If your server is not configured correctly, that script can execute on your server and give the attacker full control.

Real input validation means checking type, length, format, and range on every piece of user input, on the server side. Client-side validation in the browser is a user experience feature, not a security measure. Anyone with basic tools can bypass it entirely.

No CSRF Protection

Cross-Site Request Forgery is one of those attacks that sounds obscure until you understand it. If your user is logged into your app and visits a malicious website, that website can make requests to your app on the user’s behalf. Transfer money. Change account settings. Delete data. All without the user knowing.

AI-generated code almost never includes CSRF tokens. This is the mechanism where your server generates a unique token for each form, and rejects submissions that do not include a valid token. It is standard practice in every major web framework, but AI tools consistently skip it when generating quick prototypes.

If your app has any functionality that modifies data (and almost every app does), missing CSRF protection is a genuine risk.

Insecure Dependencies

When AI generates code, it pulls in third-party packages. Sometimes it recommends packages that have known vulnerabilities. Sometimes it recommends packages that are no longer maintained. Occasionally, it recommends packages that do not even exist, which opens the door to a supply chain attack where someone creates a malicious package with that exact name.

A real example that has affected multiple AI-generated projects: the AI recommends a specific version of a package that had a critical vulnerability patched two versions ago. The generated package.json pins to the vulnerable version because that is what was in the training data.

Cross-Site Scripting (XSS)

AI tools frequently generate code that renders user-supplied content without sanitisation. This means if a user can input text that gets displayed to other users (comments, profiles, messages, even usernames), they can inject JavaScript that executes in other users’ browsers.

This is not just about defacing your page. XSS can steal session cookies, redirect users to phishing sites, or capture keystrokes. In a business application where users might enter sensitive information, XSS is a serious data breach vector.

Modern frameworks like React handle a lot of XSS prevention automatically, but AI-generated code regularly bypasses those protections by using patterns like dangerouslySetInnerHTML or raw HTML rendering to get something to “look right” quickly.

Broken Access Control

Your app has an admin page at /admin. AI builds it with a check: if the user is an admin, show the admin content. Looks secure. But the API endpoints that the admin page calls? They often have no authorisation checks at all.

This means anyone who knows (or guesses) the API URL can access admin functionality directly, without ever touching the admin page. AI tools focus on the UI layer and frequently forget that the API layer needs its own independent authorisation.

This pattern repeats everywhere: user A should not be able to see user B’s data, but the API endpoint just accepts whatever user ID you pass it. No ownership verification. No role check. The UI only shows you your own data, but the API will happily serve anyone’s data to anyone who asks.

What to Do About It

The point of this list is not to scare you away from AI coding tools. They are genuinely useful. The point is that security is not something that happens by default. It requires deliberate, systematic effort.

If you have an AI-generated application that handles real user data, real payments, or real business processes, here is the minimum you should do:

1. Run a dependency audit and update anything with known vulnerabilities.
2. Search your codebase for hardcoded strings that look like keys, passwords, or tokens. Move them to environment variables.
3. Check every database query for direct string concatenation with user input.
4. Verify that server-side validation exists for every form and API endpoint.
5. Confirm that API routes check authorisation independently from the UI.

You do not need to be a security expert to do these checks. You need to be a business owner who understands that the cost of a data breach is measured in lawsuits, lost customers, and regulatory fines — not developer hours.