The Apps Bolt and Lovable Build Have a Problem. This Tool Was Built to Find It.

Let's Talk About What Bolt and Lovable Actually Ship

Bolt.new and Lovable are genuinely impressive pieces of software. They can scaffold a full-stack SaaS application - authentication, database, API layer, frontend, and deployment - in a single afternoon. For a non-technical founder who previously needed to hire a developer or spend months learning to code, this is transformative.

But there is a gap between "it works" and "it is ready for production." Bolt and Lovable close the first gap. They do not close the second one. And if you are deploying a Bolt or Lovable app to real users without scanning it first, you are accepting risks you almost certainly have not assessed.

This is not a bug in these platforms. It is a structural outcome of how they operate. They generate code that fulfills the user's functional requirements as efficiently as possible. Security, performance optimization, and test coverage are cross-cutting concerns that require knowledge beyond what the user typically specifies. Until the user asks for authentication, the model does not add it. Until the user asks for rate limiting, the model does not add it. The model is doing exactly what it was designed to do.

The problem is that most users do not know to ask. And when the model does add security components, it often adds them incompletely, in ways that look correct but have gaps.

What a Typical Bolt App Looks Like Under the Hood

Based on analysis of publicly available Bolt-generated applications and the results of VibeDoctor scans on user-submitted Bolt apps, a typical Bolt.new generated application in 2026 has the following characteristics:

What a Typical Lovable App Looks Like Under the Hood

Lovable's output has a different character than Bolt's. Lovable tends to generate more polished UI with better component structure and cleaner styling. The security gaps are similar but the code quality issues differ slightly:

The Pattern That Concerns Us Most

Of all the issues that appear in Bolt and Lovable generated apps, the most dangerous is also the hardest to see without a scanner: the authentication call that is present but not enforced.

// Bolt-generated API route - this is what gets built
export async function POST(request: Request) {
  const supabase = createRouteHandlerClient({ cookies });
  const { data: { session } } = await supabase.auth.getSession();
  
  const body = await request.json();
  
  // The session exists in the code - but what happens if it's null?
  // The code proceeds to the database operation regardless.
  const { data, error } = await supabase
    .from('user_data')
    .insert({ user_id: session?.user?.id, ...body });  // session?.user?.id is undefined if not logged in
    
  return NextResponse.json({ data });
}

// What it should look like
export async function POST(request: Request) {
  const supabase = createRouteHandlerClient({ cookies });
  const { data: { session } } = await supabase.auth.getSession();
  
  // Actually check and reject unauthenticated requests
  if (!session) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }
  
  const body = await request.json();
  
  const { data, error } = await supabase
    .from('user_data')
    .insert({ user_id: session.user.id, ...body });
    
  if (error) {
    console.error('Insert failed:', error);
    return NextResponse.json({ error: 'Failed to save' }, { status: 500 });
  }
  
  return NextResponse.json({ data });
}

The unauthenticated version inserts a database row with user_id: undefined for any anonymous request. If Row Level Security is not enabled on the Supabase table (which it often is not), this means any visitor to your site can insert arbitrary data into your database. With the right payload structure, this can be used to inject malicious content, exhaust your database limits, or map your schema.

How VibeDoctor Finds These Issues

VibeDoctor runs two scanning pipelines on every submission. The code pipeline clones your repository and runs five tools: Gitleaks finds secrets committed to source code; Trivy finds CVEs in your dependency tree; ESLint runs static analysis rules tuned for AI-generated JavaScript and TypeScript patterns; custom project hygiene checks verify .gitignore, README, and test directory presence; the Vibe Checks scanner runs 40+ checks specifically designed around patterns that appear in AI-generated code, including the incomplete authentication pattern above (SEC-001), client-side secret exposure (SEC-006), missing input validation (SEC-010), and 37 other checks across security, performance, testing, and code quality categories.

The live site pipeline runs simultaneously: Lighthouse performance analysis, SSL certificate checking, security header detection, JavaScript runtime error scanning in a real Chromium browser, broken link crawling, and page weight measurement.

The combination of code and live site analysis is what makes VibeDoctor different. A code-only scanner would not catch an expired SSL certificate. A site-only scanner would not catch hardcoded API keys. Most vibe-coded apps have issues in both dimensions.

What You Should Do Before Deploying Any Bolt or Lovable App

The checklist is short. If you cannot check all of these boxes manually, run VibeDoctor and let it find the gaps:

1. No secrets in NEXT_PUBLIC_ or VITE_ variables. Only your Supabase anon key and public URL should be in the frontend bundle. Service role keys, OpenAI keys, Stripe secret keys, and any other secret must stay server-side.
2. Every API route that reads or writes user data checks authentication before proceeding. Not just imports the auth library. Not just calls getSession(). Actually checks the return value and returns 401 if the session is null.
3. Row Level Security is enabled on every Supabase table. Lovable and Bolt frequently create tables with RLS disabled. Check your Supabase dashboard and enable RLS with appropriate policies.
4. No .env file committed to your Git repository. Even one historic commit with your .env file exposed means anyone who clones your repo has your credentials. VibeDoctor checks your git history as well as your current working tree.
5. Security headers are present. Add a Next.js middleware file that sets CSP, HSTS, X-Frame-Options, and Permissions-Policy. This takes 15 minutes and blocks a large class of client-side attacks.

Run Your Scan Now

Go to vibedoctor.io. Enter your Bolt or Lovable app URL and optionally connect your GitHub repository. The scan runs in minutes, no configuration required, and gives you a scored report with specific findings and remediation steps. The free tier covers everything described above with no credit card required.

If you built your app with Bolt or Lovable and you have not scanned it yet, the odds that you have at least one Critical finding are better than two in three. Run the scan before your users discover it for you.

FAQ