AI coding tools have genuinely changed how software gets built. GitHub Copilot, Cursor, Claude, ChatGPT \u2014 developers are using them to write boilerplate, generate functions, scaffold entire features, and move faster than was previously possible. The productivity gains are real and significant.<\/p>\n
But there’s a problem that doesn’t get nearly enough attention: AI coding tools produce insecure code with alarming regularity. Not because the AI is malicious \u2014 because it’s optimising for something different than security. It’s optimising for code that looks correct, compiles, and solves the immediate problem. Security is a separate dimension that the AI doesn’t automatically prioritise unless you explicitly ask it to \u2014 and even then, it makes mistakes.<\/p>\n
This guide is about what those security problems actually look like, why they happen, and what a development team needs to do to catch them before they reach production.<\/p>\n
Understanding why the problem exists helps you know what to look for.<\/p>\n
AI coding models are trained on vast amounts of publicly available code \u2014 open source repositories, Stack Overflow answers, tutorials, documentation examples. A significant portion of that code has security problems. Tutorials often skip security for brevity. Stack Overflow answers prioritise making something work over making it secure. Legacy open source code carries vulnerabilities that were never fixed. The AI learns patterns from all of this \u2014 including the insecure patterns.<\/p>\n
When you ask an AI to write a function that handles user authentication, or processes a file upload, or queries a database, it generates code based on the patterns it learned during training. If the most common pattern in its training data for that task included a SQL injection vulnerability, the AI will reproduce that pattern confidently and without warning.<\/p>\n
A second reason is that AI has no awareness of your specific application context. It doesn’t know your threat model, your data sensitivity, your regulatory requirements, or your existing security controls. It answers the question in front of it without knowing what surrounds it. A snippet of code that’s technically correct in isolation might be dangerously wrong in the context of your specific application.<\/p>\n
A third reason is that AI tools are optimised for immediate feedback \u2014 making the code work. Security problems often don’t surface immediately. An SQL injection vulnerability won’t cause a test failure. An insecure file upload handler will pass all functional tests. The AI has no mechanism to discover these problems through the feedback loop it’s optimising for.<\/p>\n
SQL Injection<\/strong> remains one of the most common vulnerabilities in AI-generated code. When you ask an AI to write a database query, it frequently generates code that concatenates user input directly into query strings \u2014 the textbook SQL injection pattern. This is especially common in older-style PHP code, raw SQL queries, and examples that predate modern ORM usage.<\/p>\n A vulnerable pattern an AI might generate:<\/p>\n The correct approach uses prepared statements or a query builder that handles parameterisation automatically:<\/p>\n In Laravel, the Eloquent ORM handles this automatically \u2014 but if you ask an AI to write raw DB queries for performance, it may revert to unsafe patterns. Always use parameter binding when writing raw queries.<\/p>\n Insecure Direct Object References (IDOR)<\/strong> are extremely common in AI-generated API code. When an AI writes a route that retrieves a resource by ID \u2014 a user record, an order, a file \u2014 it frequently forgets to verify that the authenticated user actually has permission to access that specific resource. The code checks that the user is logged in, but not that the resource belongs to them.<\/p>\n This vulnerability allows any authenticated user to access any other user’s data simply by changing an ID in the URL. It’s trivially exploitable and AI generates this pattern frequently.<\/p>\n Hardcoded credentials and secrets<\/strong> appear regularly in AI-generated code \u2014 especially in configuration examples, database connection code, and API integration snippets. The AI generates working code with placeholder or example credentials that look real. Developers copy the pattern, replace the placeholder with their actual credentials, and commit it to version control without thinking.<\/p>\n API keys, database passwords, JWT secrets, and third-party credentials should never appear in source code. They belong in environment variables, loaded from a secrets manager in production. AI tools frequently generate the insecure pattern because training data is full of it.<\/p>\n Missing input validation and sanitisation<\/strong> is a broad category that AI-generated code handles inconsistently. File uploads are a particularly dangerous example. AI-generated file upload handlers frequently skip MIME type validation, accept any file extension, store files in publicly accessible directories, and use the original filename without sanitisation \u2014 creating multiple overlapping vulnerabilities.<\/p>\n Broken authentication patterns<\/strong> appear when developers ask AI to implement custom authentication rather than using established libraries. JWT handling is a common example \u2014 AI-generated JWT validation code frequently misses critical checks: verifying the algorithm, checking token expiration, validating the signature correctly. Using Laravel Sanctum, Passport, or a well-maintained auth library is almost always safer than AI-generated custom authentication.<\/p>\n Exposed sensitive data in API responses<\/strong> happens because AI-generated API endpoints frequently return entire database records rather than carefully scoped response objects. A user endpoint that returns the full User model will include password hashes, email addresses, internal IDs, and other sensitive fields that should never be exposed to the client.<\/p>\n Missing rate limiting<\/strong> on sensitive endpoints is consistently absent from AI-generated code. Login endpoints, password reset flows, OTP verification, and API endpoints that consume external services should all have rate limiting \u2014 both to prevent brute force attacks and to control costs. AI generates functional endpoint code without this protection unless explicitly asked.<\/p>\n Insecure CORS configuration<\/strong> is a problem in AI-generated backend code for SPAs and mobile apps. The quickest way to make a CORS error disappear \u2014 which is what the AI optimises for \u2014 is to allow all origins. This is appropriate for fully public APIs but catastrophic for APIs that handle authenticated user data.<\/p>\n A natural response to AI security risks is “we’ll catch them in code review.” This is partially true but overconfident in practice.<\/p>\n When code review volume increases \u2014 as it does when AI tools significantly accelerate code production \u2014 review quality degrades. Reviewers spend more time reading more code and have less cognitive bandwidth per line. Security-relevant issues that require careful thought about attack scenarios are the first things to get missed when reviewers are moving fast.<\/p>\n AI-generated code often looks clean and well-structured, which creates a false sense of safety. A reviewer who sees properly formatted, well-commented code with sensible variable names is less likely to scrutinise it carefully than messy, obviously rushed code. The security problem isn’t visible at a surface level \u2014 it requires understanding what the code does in adversarial conditions, not just whether it works in the happy path.<\/p>\n Reviewers who are themselves using AI tools for their own work are increasingly accustomed to patterns that AI produces \u2014 including insecure ones. If everyone on the team has normalised AI-generated query patterns, a SQL injection vulnerability in a code review might not register as wrong.<\/p>\n Add security requirements to your AI prompts explicitly.<\/strong> When using an AI tool to write code that handles user input, authentication, database queries, or file operations \u2014 specify your security requirements in the prompt. “Write a file upload handler for Laravel that validates MIME type, rejects executables, randomises the filename, and stores files outside the web root” produces significantly more secure output than “write a file upload handler.”<\/p>\n Ask the AI to review its own output for security issues as a second step: “Review this code for OWASP Top 10 vulnerabilities and suggest fixes.” This isn’t foolproof \u2014 the AI can miss things \u2014 but it catches obvious problems and builds security thinking into the workflow.<\/p>\n Use static analysis tools as part of your CI pipeline.<\/strong> Static analysis tools examine code for known vulnerability patterns automatically, without requiring human reviewers to catch everything manually. For PHP and Laravel projects, tools like PHPStan at a high rule level, Psalm, and Enlightn (specifically designed for Laravel security) catch many of the vulnerability patterns that AI generates. These should run on every pull request and block merging when they find critical issues.<\/p>\n For JavaScript and Node.js projects, npm audit catches known vulnerable dependencies. ESLint with security plugins catches common JavaScript security patterns. For Python projects, Bandit performs similar static security analysis.<\/p>\n Run dependency audits regularly.<\/strong> AI tools sometimes suggest outdated package versions that have known vulnerabilities, or generate package.json and composer.json entries that pull in vulnerable transitive dependencies. Automated dependency scanning \u2014 GitHub Dependabot, Snyk, or similar \u2014 should flag vulnerable dependencies before they reach production.<\/p>\n Conduct dedicated security-focused code reviews for high-risk code.<\/strong> Not every file needs the same level of security scrutiny, but some areas deserve focused attention: authentication and authorisation logic, anything that handles file uploads or user-supplied input, API endpoints that return sensitive data, payment processing flows, and any code that touches external systems. For these areas, a separate security-focused review pass \u2014 specifically looking for OWASP Top 10 vulnerabilities \u2014 is worth the time.<\/p>\n Use API Resources and Form Requests consistently in Laravel.<\/strong> These two patterns address multiple AI-generated security problems simultaneously. Form Requests enforce input validation at the controller boundary, making it much harder for unvalidated input to reach business logic. API Resources provide explicit control over what data is serialised into responses, preventing accidental data exposure. Both are patterns that AI tools often skip in favour of more direct approaches \u2014 make them mandatory in your project standards.<\/p>\n Environment variable hygiene needs to be a hard rule.<\/strong> No credentials, API keys, or secrets in source code \u2014 ever. This means a .env.example file with placeholder values, .env in .gitignore, a documented process for sharing secrets with new team members through a secrets manager or encrypted channel, and automated scanning for accidental credential commits using tools like GitGuardian or git-secrets in your pre-commit hooks.<\/p>\n Penetration testing before major releases.<\/strong> Static analysis and code review catch pattern-based vulnerabilities but miss logic flaws \u2014 vulnerabilities that arise from how components interact rather than how individual functions are written. A penetration test \u2014 even a focused, time-boxed one \u2014 on a significant new feature or before a major release catches these logic-level issues. For applications handling sensitive data or financial transactions, this is not optional.<\/p>\n The goal isn’t to stop using AI coding tools \u2014 the productivity benefits are too significant. The goal is to build a workflow where AI handles the speed and AI introduces security debt gets caught systematically before it ships.<\/p>\n This means treating AI-generated code with appropriate scepticism \u2014 not the unquestioning trust that comes from seeing clean, well-formatted output. It means adding security tooling to your pipeline that doesn’t depend on human reviewers catching everything. It means building team habits around explicit security prompting when using AI for sensitive code paths. And it means accepting that using AI tools increases the responsibility to review and validate, not decreases it.<\/p>\n The developers and teams that use AI tools safely aren’t the ones who avoid them. They’re the ones who understand the specific failure modes and have built systematic defences against each of them.<\/p>\n\/\/ VULNERABLE \u2014 never do this\r\n$query = \"SELECT * FROM users WHERE email = '\" . $_POST['email'] . \"'\";\r\n$result = mysqli_query($conn, $query);<\/code><\/pre>\n\/\/ SECURE \u2014 parameterised query\r\n$stmt = $pdo->prepare(\"SELECT * FROM users WHERE email = ?\");\r\n$stmt->execute([$_POST['email']]);<\/code><\/pre>\n\/\/ VULNERABLE \u2014 missing ownership check\r\nRoute::get('\/orders\/{id}', function ($id) {\r\n return Order::findOrFail($id); \/\/ Returns any order regardless of who owns it\r\n});\r\n\r\n\/\/ SECURE \u2014 verify ownership\r\nRoute::get('\/orders\/{id}', function ($id) {\r\n $order = Order::where('id', $id)\r\n ->where('user_id', auth()->id())\r\n ->firstOrFail();\r\n return $order;\r\n});<\/code><\/pre>\n\/\/ VULNERABLE \u2014 credentials in code\r\n$client = new StripeClient('sk_live_actualrealkey123456789');\r\n\r\n\/\/ SECURE \u2014 credentials in environment variables\r\n$client = new StripeClient(env('STRIPE_SECRET_KEY'));<\/code><\/pre>\n\/\/ VULNERABLE \u2014 missing validation\r\nif ($_FILES['upload']['error'] === 0) {\r\n move_uploaded_file(\r\n $_FILES['upload']['tmp_name'],\r\n 'uploads\/' . $_FILES['upload']['name'] \/\/ original filename, any extension\r\n );\r\n}\r\n\r\n\/\/ SECURE \u2014 validate type, randomise name, restrict location\r\n$allowedTypes = ['image\/jpeg', 'image\/png', 'image\/webp'];\r\n$file = $request->file('document');\r\n\r\nif (!in_array($file->getMimeType(), $allowedTypes)) {\r\n abort(422, 'File type not allowed');\r\n}\r\n\r\n$filename = Str::uuid() . '.' . $file->extension();\r\n$file->storeAs('private\/uploads', $filename); \/\/ Not publicly accessible<\/code><\/pre>\n\/\/ VULNERABLE \u2014 exposes all fields including password hash\r\nreturn response()->json(User::find($id));\r\n\r\n\/\/ SECURE \u2014 explicit field selection using API Resource\r\nreturn new UserResource(User::find($id));\r\n\/\/ UserResource only returns: id, name, avatar, created_at<\/code><\/pre>\n\/\/ VULNERABLE \u2014 allows any origin\r\nheader(\"Access-Control-Allow-Origin: *\");\r\n\r\n\/\/ SECURE \u2014 explicit allowed origins\r\n'allowed_origins' => [env('FRONTEND_URL', 'https:\/\/app.yourdomain.com')],<\/code><\/pre>\nWhy Code Reviews Don’t Always Catch These<\/h2>\n
What to Actually Do About It<\/h2>\n
Building Security Into Your AI-Assisted Development Workflow<\/h2>\n