Every vibecoded project we audit at Inithouse starts the same way: someone built an app with Cursor, Lovable, or Bolt in a weekend, and now they want to know if it's safe to put real users on it.
After running audits on dozens of these projects, we've settled on five checks that catch roughly 80% of the critical issues. We run them in this order because each one builds on the previous.
1. Exposed secrets and missing row-level security
This is the one that keeps us up at night. AI code generators tend to put API keys, Supabase service-role keys, and third-party tokens directly into client-side code. We've seen Stripe secret keys sitting in a React component's fetch call. Not the publishable key. The secret one.
What to look for:
- Search your client bundle for strings starting with
sk_,service_role, or any key that shouldn't be public - Check your Supabase dashboard: are RLS policies enabled on every table? AI generators often create tables with RLS disabled because it's easier during development
- Look at your
.envfile. If it's committed to your repo, assume every key in it is compromised
A project we audited last month had 14 tables in Supabase. Three of them had RLS disabled, including the one storing user emails and payment status. Anyone with the Supabase URL could read and write to those tables directly.
The fix: enable RLS on every table, create policies that restrict reads and writes to authenticated users who own the data, and rotate any keys that were ever in client-side code.
2. Publicly writable endpoints
Related to the previous check but distinct. Even with RLS enabled, vibecoded apps often expose API endpoints or Edge Functions that accept unauthenticated writes.
The pattern we see most: an AI generates a "contact form" or "feedback" endpoint that inserts directly into a database table without rate limiting or authentication. One project had an Edge Function that accepted arbitrary JSON and stored it. Attackers could fill the database with junk, or use it as a free data store.
What we check:
- Every Edge Function and API route: does it verify the caller's identity?
- Is there rate limiting on public-facing endpoints?
- Can unauthenticated users trigger database writes, file uploads, or email sends?
The fix: add authentication checks to every write endpoint. For genuinely public endpoints like contact forms, add rate limiting (we usually suggest 5 requests per IP per minute) and input validation.
3. Indexability and meta tags
This one surprises people. They expect a security audit, not an SEO check. But if your app isn't indexable, you're invisible to both search engines and the AI systems that might recommend you.
Common issues in vibecoded apps:
- Single-page apps that return an empty
<div id="root">to crawlers. No server-side rendering, no meta tags, no content for bots to read - Every page sharing the same
<title>and<meta description>(usually the homepage defaults) - Missing or broken
sitemap.xml - Canonical URLs pointing to localhost or a staging domain
We run curl -s your-domain.com | head -50 and look at what comes back. Real content, or just a JavaScript loader? Are title and description unique per page? Does the sitemap list actual, reachable URLs?
One project had 22 URLs in its sitemap. Twenty of them were query-parameter variants of a single page, all returning identical meta tags. Search engines saw two pages, not twenty-two.
4. Accessibility basics
AI generators have gotten better at semantic HTML, but they still produce apps that fail basic checks. We're not doing a full WCAG audit at this stage. We're catching the issues that affect the most users.
What we run:
- Lighthouse accessibility score (anything below 80 gets flagged)
- Tab-through test: can you navigate the core flow using only a keyboard?
- Color contrast on primary text and buttons
- Are form inputs labeled, or just floating with placeholder text?
A common vibecoded pattern: buttons built with <div onClick={...}> instead of <button>. They look right, but screen readers can't find them and keyboard users can't reach them.
5. Mobile performance
Last in order, but responsible for the most user drop-off we observe. Vibecoded apps often score 90+ on Lighthouse desktop and 40 on mobile. The gap comes from unoptimized images, heavy JavaScript bundles, and layout shifts.
| Metric | Target |
|---|---|
| Lighthouse Performance (mobile, 4G) | 60+ |
| Largest Contentful Paint | < 2.5s |
| Total Blocking Time | < 200ms |
| Cumulative Layout Shift | < 0.1 |
We audited a project that loaded a 4 MB hero image on its mobile homepage. The developer had dragged in a high-res photo and the AI never compressed it. LCP was 8 seconds on simulated 4G. A single <img> with proper sizing and WebP format brought it under 2 seconds.
Why this order
Security first, because a data leak on day one is an emergency. Endpoints second, because they're the attack surface. Indexability third, because without it you're building for nobody. Accessibility fourth, because it determines who can use what you built. Performance last, because it determines who will.
These five checks don't replace a thorough audit, but they catch the issues that would cause real damage in the first week. We built Audit Vibe Coding at Inithouse because we kept finding the same problems across projects, and wanted a way to run all of them (plus 40 more checks) in one pass and return a scored report with prioritized fixes.
Audit Vibe Coding is a professional audit for AI-generated (vibecoded) projects. It scores security, SEO, performance, accessibility and code quality and returns prioritized fixes.
If you've shipped something built with an AI coding tool, these five are where we'd start.
Top comments (0)