5 Security Mistakes AI Coding Tools (Cursor, v0, Lovable) Make—and How to Fix Them

Title: 5 Security Mistakes AI Coding Tools (Cursor, v0, Lovable) Make—and How to Fix Them

AI tools like Cursor, Lovable, v0, and Bolt have made building web applications fast and accessible. You can go from an idea to a working full-stack prototype in a weekend.

However, these models prioritize functional code over defensive security. When generating rapid prototypes, AI generators routinely leave open security vulnerabilities in your database, repository, and deployment configs.

Here are 5 common security blunders found in AI-generated apps and how to patch them before going live.

1. Disabled Row Level Security (RLS) in Supabase

AI generators often create Postgres tables without enabling RLS, or they write permissive policies so the app "just works" during initial testing.

The Risk: If RLS is disabled, anyone with your public anon API key can query your entire table using the Supabase client.

The Fix: Always enable RLS and explicitly scope access to authenticated owners.

sql
-- Enable RLS
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

-- Owner-only access policy
CREATE POLICY "Users can view own profile" 
ON public.profiles 
FOR SELECT 
USING (auth.uid() = user_id);

2. Leaked API Keys in Client Components
It’s easy to ask an AI tool to "add Stripe checkout" or "integrate OpenAI," only for it to hardcode a secret key directly into a React component like Checkout.tsx.

The Risk: Front-end code is bundled and delivered directly to the browser. Anyone inspecting your JavaScript bundle can extract your secret keys.

The Fix:

Move API calls to serverless functions or API routes.

Reference keys via environment variables on the server side (process.env.STRIPE_SECRET_KEY).

Add .env and .env.local to your .gitignore.

3. Wildcard CORS headers in vercel.json
When debugging CORS errors, AI tools frequently suggest adding wildcard origin headers to your deployment configuration.

JSON
// BAD: vercel.json
{
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "*" }
      ]
    }
  ]
}
The Risk: Allowing wildcard origins lets third-party domains make credentialed API requests on behalf of users visiting another site.

The Fix: Restrict origin headers explicitly to your production domain:

JSON
{
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "[https://yourdomain.com](https://yourdomain.com)" }
      ]
    }
  ]
}
4. Anonymous SELECT on Sensitive Columns
Even when RLS is enabled, AI prompts frequently set up policies that allow anon roles to perform SELECT queries without restricting which columns are returned.

The Risk: Exposing columns containing email addresses, user IDs, or internal metadata to unauthenticated users.

The Fix: Create separate public views or restrict query permissions using helper functions (e.g., checking has_role()).

5. Exposed Preview Deployments with Stale Secrets
Vercel and Netlify automatically build preview deployments for every Git branch or pull request. AI workflows often leave old test branches active with exposed credentials.

The Fix: Audit your deployment dashboard regularly and delete stale preview deployments or ephemeral environment variables that are no longer in use.

Automating Pre-Launch Checks
Checking every table policy, API route header, and bundle manually before every launch takes time.

If you want to automate these exact checks, I built StackShield (https://stackshield.org)—a lightweight pre-launch security scanner for apps built with vibe-coding tools. It connects to your GitHub, Supabase, and Vercel projects, flags these specific misconfigurations in under 90 seconds, and opens PRs to fix them.

What security oversights have you caught in AI-generated code? Drop them in the comments below!