A security checker for vibe coded apps built with Lovable, Bolt, Cursor and v0

What a security checker for vibe coded apps should catch

Most vibe-coded apps share the same shape: a JavaScript frontend, a hosted backend such as Supabase or Firebase, and a handful of third-party API keys. The risks live at the seams between those pieces. A useful checker looks at what your deployed site actually sends to a browser, not just the code in your editor.

• Exposed API keys and secrets. Keys for OpenAI, Anthropic, Stripe (secret keys), AWS or a Supabase service_role key that ended up in the shipped JS bundle. Anything in the bundle is public, even if it never appears in your git repo.
• Supabase Row Level Security. Whether tables can be read with the public anon key and no login. The anon key is meant to be public; RLS is what protects the data.
• Firebase rules. Whether Realtime Database, Firestore or Storage still allow public reads, which is common when a project started in test mode.
• Open storage buckets. Supabase Storage buckets that anyone can list, which can expose user uploads.
• Security headers and HTTPS. Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options and a working HTTP-to-HTTPS redirect.
• CORS. Whether your server echoes back any origin with credentials allowed, which would let another website read your logged-in users' data.
• Vulnerable JavaScript libraries. Old versions of common libraries with known CVEs.
• Exposed files. Publicly downloadable .env, .git, source maps and debug or admin endpoints.
• Email spoofing protection. SPF and DMARC records, so nobody can easily send email that looks like it came from your domain.

Common mistakes in Lovable, Bolt, v0 and Cursor apps

None of these tools are insecure by design, but they optimize for "it works", and the defaults they generate are not always the defaults you want in production.

• Lovable and Bolt with Supabase: tables created during prototyping without RLS, or with a policy like using (true) that lets everyone read everything. Ask the AI to "make it work" after a permissions error and it may loosen the policy instead of fixing the query.
• v0 and Next.js: secrets given a NEXT_PUBLIC_ prefix so a client component can use them. That prefix inlines the value into the browser bundle.
• Cursor and other editor agents: AI API calls made straight from the frontend with a hardcoded key, committed .env files, and production builds that ship source maps.
• Everywhere: Firebase projects still on test-mode rules, no security headers configured at the host, and a custom domain with no DMARC record.

For tool-specific steps, see our Supabase RLS checklist, Lovable API key guide and Cursor, Bolt and v0 checklist.

How PreflightVibe works

1. Paste your live URL. Confirm you own it or have permission to test it.
2. We scan from the outside. Read-only GET requests and DNS lookups, no logins, no form submissions, no exploits. If a Supabase or Firebase config is in your public bundle, we use that same public key to check whether up to 8 tables, your storage buckets or your Firebase data can be read without login. We keep only names and counts, never row values.
3. Get an A–F grade with findings in plain English across security, deploy blockers and basic SEO/performance.
4. Fix it with your AI tool. The full report includes copy-paste fix prompts for Cursor, Claude Code, Lovable, Bolt and v0, exact RLS SQL for Supabase and rules for Firebase.
5. Re-check. Run the scan again and see what is fixed, still open and new.

Optionally, scan your code too: paste a public GitHub repo URL or upload a ZIP and we look for committed secrets in current files and recent history. Files are deleted when the scan finishes.

What it doesn't do: it is not a penetration test. It can't see your server code or log in, so it can't tell whether user A can read user B's data. Test that yourself with two accounts. The library check covers a short list (jQuery, lodash, AngularJS, Bootstrap, Next.js), so still run npm audit.

Pricing

• Free quick scan: every check runs. You see your grade, counts by severity, every biggest risk (leaked keys and open data) and your top finding in full. No signup.
• $29 full report, one-time: evidence, plain-English fixes and AI fix prompts for every finding. 14-day full refund if it wasn't useful, plus a free re-check within 7 days.
• $12/mo re-check (optional): automatic weekly rescans with an email alert when something new breaks. Cancel anytime.

FAQ

What is a security checker for vibe coded apps?

A security scanner built for apps generated with AI coding tools like Lovable, Bolt, Cursor, Replit and v0. It focuses on the mistakes those apps make most often: keys in the browser bundle, Supabase tables without RLS, Firebase test-mode rules, public buckets, missing headers and exposed config files.

Is the Supabase anon key in my frontend a problem?

Not by itself. The anon key is meant to be public. It becomes a problem when RLS is off or too permissive, because anyone with that key can read your tables. The service_role key must never be in frontend code.

Does PreflightVibe attack or change my app?

No. Read-only requests and DNS lookups only. No logins, no writes, no exploits, and we never store row values or file names. You must own the URL or have permission.

Do I need to connect GitHub?

No. The main scan only needs your live URL. The optional code scan takes a public repo URL (no tokens) or a ZIP.

Is this a replacement for a penetration test?

No. It is an automated launch checklist for common vibe-coding mistakes. If you handle payments, health data or other sensitive information, get a professional review as well.

How much does it cost?

Free quick scan; $29 one-time full report with a 14-day refund and a free re-check; optional $12/mo weekly re-checks.