Vibe Coding Security Risks: What AI-Built Apps Get Wrong

AI coding tools have changed how fast you can build a web application. Cursor, Copilot, and Windsurf can scaffold an entire app in hours. You describe what you want, the tool writes the code, and you ship it. The productivity gains are real.

The security gaps are also real.

I've been looking at web applications built with AI coding tools, and the same issues appear consistently. Not exotic vulnerabilities. Basic configuration mistakes that exist because the tools optimise for functionality, not security.

This isn't an argument against AI-assisted development. It's a checklist of the things these tools consistently miss, so you can fix them before shipping.

What AI coding tools are good at

Before the criticism, credit where it's due. AI coding tools are genuinely good at generating functional code, building UI components, implementing CRUD operations, handling state management, writing API routes, and setting up authentication flows using established libraries.

If you ask for a login page with email and password, you'll get a working login page. The HTML will be semantic, the form will submit correctly, and the API route will handle the request. Functionally, it works.

The problems are in the things you don't ask for.

Security headers: almost never added

This is the most consistent gap. AI coding tools generate Next.js, Express, or SvelteKit applications without any security headers configured. No Content-Security-Policy, no HSTS, no X-Content-Type-Options, no X-Frame-Options.

These headers aren't part of the application logic, so the tool doesn't think to add them. But they're critical for protecting your users against XSS, clickjacking, and man-in-the-middle attacks.

The fix takes five minutes. Add a headers() function in your Next.js config or a middleware in Express. But you have to know to do it, and the tool won't remind you.

CORS: defaulting to permissive

When an AI coding tool sets up an API that needs to handle cross-origin requests, the default is often Access-Control-Allow-Origin: *. This makes sense during development because it stops CORS errors from blocking your work. But it should never reach production.

I've seen apps with * CORS in production because the developer never revisited the generated configuration. The tool solved the immediate problem (the CORS error) without considering the security implication (any website can now call your API).

Input validation: surface-level at best

AI tools typically validate that inputs exist and have the right type. They check that an email field contains something that looks like an email, that numbers are actually numbers, and that required fields aren't empty.

What they rarely do is validate input for security. SQL parameterisation is usually handled by ORMs, which is good. But protection against XSS in user-generated content, path traversal in file uploads, and SSRF in URL inputs is often missing entirely.

The tool generates code that handles the happy path. The attack paths require explicit consideration.

Environment variables: exposed accidentally

AI coding tools are good at using environment variables for secrets. They'll put your database URL, API keys, and JWT secrets in .env files. But they sometimes get the boundary wrong.

In Next.js, any environment variable prefixed with NEXT_PUBLIC_ is included in the client-side JavaScript bundle. AI tools sometimes use this prefix for variables that shouldn't be public, because the tool's immediate goal is making the code work in the browser, not protecting the secret.

Check every NEXT_PUBLIC_ variable in your code. If it contains a secret key, a database credential, or an API key that shouldn't be visible to users, remove the prefix and access it only in server-side code.

Cookie configuration: missing flags

When AI tools implement session management, the cookies often work but lack security attributes. The HttpOnly, Secure, and SameSite flags are frequently missing because they're not required for functionality.

Without HttpOnly, JavaScript can read your session cookie (XSS risk). Without Secure, the cookie is sent over HTTP (interception risk). Without SameSite, the cookie is sent with cross-site requests (CSRF risk).

Rate limiting: rarely considered

AI tools generate API routes that handle requests correctly but don't limit how many requests a single client can make. This leaves your API vulnerable to brute-force attacks on login endpoints, credential stuffing, and resource exhaustion.

Adding rate limiting is rarely part of the initial prompt, and the tool won't add it unprompted.

Error handling: too informative

Good error handling from a development perspective (detailed error messages, stack traces, database query details) is bad from a security perspective. AI-generated error handlers often return too much information in production, including internal paths, library versions, and database structure.

Make sure error responses in production return generic messages to the user while logging the details server-side.

What to do about it

None of these issues are difficult to fix. The challenge is knowing they exist. Here's a practical workflow:

After the AI generates your app and before you deploy:

Add security headers (CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy)
Restrict CORS to your specific frontend domain
Check every NEXT_PUBLIC_ (or equivalent) environment variable
Add HttpOnly, Secure, and SameSite to all session cookies
Add rate limiting to authentication and sensitive endpoints
Set error handling to return generic messages in production
Run a security scan to catch anything you missed

That last step is where automated tools help. Run your deployed URL through Hexora at hexora.uk before you share it with anyone. It checks headers, CORS, cookies, SSL, exposed secrets, and DNS configuration in under 15 seconds. It won't catch everything (input validation and business logic need manual review), but it catches the configuration issues that AI tools consistently miss.

Build fast, then harden

AI coding tools are a net positive for development. They let solo developers and small teams build things that would have taken months a few years ago. But the speed that makes them powerful also makes it easy to ship before the security layer is in place.

The fix isn't to stop using AI tools. It's to add a five-minute security pass before every deploy. The tools handle the 90% that's functional. You handle the 10% that's protective.