Research & Guides
Security for AI-built apps
Practical guides on the vulnerabilities AI tools generate. And how to fix them.
The Pre-Launch Security Workflow for AI-Built Apps: Sieve + VibeScan
A concrete three-step security workflow before you share your Lovable, Bolt, or Cursor app with anyone: scan local IDE history with Sieve, scan the deployed URL with VibeScan, and lock it in with a Claude system prompt and GitHub Actions check.
Your AI Coding Assistant Is Saving Your API Keys. Here's How to Find Them.
Claude Code, Cursor, and VS Code store every conversation in local databases. When you paste .env files or API keys into AI chat, those secrets persist indefinitely — here's how to scan and redact them.
Mini Shai-Hulud: The TanStack Supply Chain Attack and What Vibe Coders Need to Do Now
CVE-2026-45321 compromised 84 @tanstack npm packages in a 6-minute window. Here's what happened, whether you're affected, and the exact steps to take.
Why AI Code Generators Keep Producing the Same Security Vulnerabilities
CVE-2025-48757 wasn't a one-off. The same RLS pattern shows up across Lovable, Bolt, and Cursor apps. Here's why — and what has to change.
I Scanned 61 AI-Built Apps — Here's What I Found
Two weeks of real VibeScan data: Twilio keys hardcoded in JS, live Stripe secrets exposed, 87% missing security headers. The patterns AI tools keep generating.
CVE-2025-48757: Lovable RLS Vulnerability — Check If You're Exposed
170+ Lovable apps exposed their entire database via missing Supabase RLS. Check if your app is affected and fix it in 5 minutes.
Supabase RLS Misconfiguration: Why 'Enabled' Doesn't Mean Secure
65% of AI-built Supabase apps have RLS enabled but still expose user data. USING (true) ≠ protected. Here's the correct policy and how to fix it in minutes.
AI-Built App Security Checklist: 10 Checks Before You Launch
Don't ship your Lovable or Bolt app without these 10 security checks — RLS, exposed secrets, auth bypass, missing headers, and 6 more, each with a fix prompt.
Lovable App Security Mistakes That Get You Hacked (And How to Fix Them)
Three RLS and auth patterns AI builders repeatedly get wrong — with real examples from live Lovable apps and the exact Supabase fixes.
Why AI-built apps need a different kind of security review
AI coding tools (Lovable, Bolt, Cursor, Claude Code, v0) ship working code fast. The problem is that “working” and “secure” are not the same thing. AI models are trained to produce code that passes tests and satisfies prompts. They are not trained to reason about attacker intent, data exposure at scale, or the gap between what a developer meant and what the code actually permits.
The result is a consistent set of vulnerability classes that show up across every independent audit of AI-generated code: credentials left in client bundles, Row Level Security policies that are syntactically valid but semantically open, authentication logic with a missing ! operator that inverts the check, and security headers that are simply absent because no one asked for them.
What you'll find in this research
Supabase RLS deep dives
Row Level Security is the primary data access control in Supabase-backed apps. AI tools generate RLS policies that look correct but are wide open. We cover the exact policy patterns to audit, what USING (true) really means, and how to write policies that actually scope to the authenticated user.
CVE analysis and incident breakdowns
When a vulnerability in an AI platform is disclosed, we break down what happened, why the AI generated it, and what developers should look for in their own apps. CVE-2025-48757 (Lovable), CVE-2025-54136 (Cursor MCP RCE), and related disclosures are covered with technical detail.
Pre-launch security checklists
Actionable checklists for developers shipping AI-built apps to real users. Covering secrets management, header configuration, auth logic review, dependency auditing, and Supabase-specific surface area. Designed to be run in one session before a launch.
Platform-specific guidance
Security defaults differ across Lovable, Bolt, Cursor, and Claude Code. Each platform has its own patterns and failure modes. Our guides are written for the specific stack and scaffolding each tool generates.
The research methodology
Our analysis draws from published third-party audits (PreBreach, VibeWrench, ShipSafe, Lorikeet Security), CVE disclosures, community-reported incidents, and direct scanning of public app surfaces. We do not exploit live apps or access private data. All vulnerability examples come from published sources or apps whose owners have consented to analysis.
Where we make statistical claims (such as 87% of AI-built apps having high or critical vulnerabilities), we cite the specific audit or dataset the number comes from. The findings are consistent across multiple independent sources, which gives us confidence the patterns are real and widespread rather than artifacts of a single methodology.