Vibe Coding: The Hidden Security Risks of AI-Driven Development

Introduction

After recently passing my CSTL exam, I found myself looking for a new project to further my web skills and keep things interesting. I decided the best approach was to build a full-stack application from the ground up, with a focus on making it as professional as possible. I wanted to use the production services typical of a large business to truly understand how all these moving parts integrate.

As part of this experiment, I decided to “vibe code” the entire application. My goal was to see how quickly I could move by letting an AI agent take the lead, while specifically keeping an eye out for the security mistakes it might make along the way.

The Plan

For this project, I chose to use Claude Code. It is currently one of the most popular tools for developers and is widely seen as one of the best coding agents on the market.

My plan was to build out a complete ecosystem: a front-end website, an integrated API, and a product designed to consume that API. The system needed full authentication and session management, all utilising Role-Based Access Control (RBAC). It was an ambitious setup, but exactly the kind of environment where security oversights tend to hide.

The Main Security Risks

As I let the AI take control, several significant security flaws began to emerge. Here are the most concerning issues I encountered during the process.

1. Pushing Sensitive Code to Docker Hub

When it came time to push my code to a User Acceptance Testing (UAT) environment, I gave Claude Code full control. I was hosting a web server on AWS and using Docker to containerise my services, so I let the AI decide the best way to handle the deployment.

To my surprise, the AI decided the best course of action was to push all of my code to a public repository on Docker Hub. Because I hadn’t explicitly restricted this, my backend source code and sensitive API keys were suddenly accessible to the entire world.

As a web tester, I know that backend source code is an absolute gold mine. It allows an attacker to perform a full code review, making it significantly easier to find deep-seated logic flaws or hidden vulnerabilities that might be missed in a standard black-box test.

2. Storing Secrets in .env Files

The second issue I noticed was how the AI handled credentials. It defaulted to storing all passwords and API keys in a .env file. While this is certainly better practice than hardcoding keys directly into the source code, it still presents a major risk. If an attacker manages to achieve Remote Code Execution (RCE) on the server, those .env files are immediately accessible.

I also noticed that the AI model would frequently access these files and change the values autonomously. If you care about data privacy and the integrity of your secrets, I would not recommend giving an AI model like Claude Code total freedom over your environment files.

3. The “Eager to Please” Problem

One of the most interesting risks I found was the AI’s tendency to prioritise functionality over safety. At one point, I wanted to add a feature to create new categories in the app. When it didn’t work the first time, I told the AI to fix the error and get the feature working at all costs.

It did exactly what I asked: it fixed the bug, but it created a Stored XSS vulnerability in the process. This highlights a much larger issue with “vibe coding.” The AI is so focused on delivering the requested feature that it will often ignore security best practices just to get the code running.

4. Default Credentials

When setting up the various databases for the project, the AI consistently used default or poorly configured credentials, such as admin. This laziness also extended to the creation of initial user accounts, where the AI would set up administrative users with standard, easily guessable default passwords. I had to manually intervene and tell the AI to change these default credentials to prevent the kind of basic security oversights that are so common in real-world breaches.

5. Misconfiguration of Headers and Rate Limiting

The AI also struggled with modern security headers. By default, it tried to implement X-XSS-Protection, which is a deprecated header that provides no real defence against modern XSS attacks. Worse still, it configured the Content Security Policy (CSP) with unsafe-inline and unsafe-eval, effectively stripping away the protections a CSP is supposed to provide.

Perhaps the most technical oversight occurred when setting up rate limiting for an API endpoint. The AI decided to use the X-Forwarded-For header to identify and block users by their IP address. This is a classic mistake: an attacker can easily bypass this by supplying their own X-Forwarded-For header and changing the IP address on every request, rendering the rate limiting completely useless.

Conclusion

The issues I have highlighted here are just a few of the most significant flaws I found during my project. If I didn’t have a background in web application security and simply wanted to pump out code as fast as possible, I would have ended up in a cybersecurity nightmare. It could easily have turned into a horror story where a leaked API key leads to a £20,000 bill overnight.

If you are building with AI, please be careful. The model I used was incredible: it allowed me to build an application in a matter of weeks that, five years ago, would have required a team of five developers and tens of thousands of pounds. I am a huge supporter of AI-driven development, but we must ensure the proper safety measures are in place. Before you ever make an AI-generated application live, make sure you are checking it for these common vulnerabilities.