Why We Built VibeWShield

In early 2025 our team reviewed a batch of apps built with Lovable and Bolt. Small SaaS products, mostly — CRMs, scheduling tools, internal dashboards. We were helping friends ship.

By the fifth review we'd seen the same bug three times. By the tenth we stopped reading the code first and started with a checklist:

1. Is there a NEXT_PUBLIC_ variable that shouldn't be there? (8/10 apps: yes.)
2. Does the Supabase RLS policy say USING (true)? (6/10: yes.)
3. Is the admin check {user?.role === 'admin' && ...} the only barrier? (9/10: yes.)
4. Is /api/admin/* reachable without a session? (7/10: yes.)
5. Is a Stripe test key in production? (3/10: yes.)

We weren't reviewing diverse failure modes. We were reviewing the same failure mode over and over, because AI coding tools produce similar code on similar prompts.

What the existing tools said

We ran OWASP ZAP, Burp Community, and Detectify on a representative sample. All three found the easy stuff — missing headers, maybe a reflected XSS. None of them flagged:

• role === "admin" client check as a security issue.
• USING (true) RLS as a vulnerability (because the policy technically exists).
• NEXT_PUBLIC_* variables containing secrets (because their scanners didn't parse Next.js bundle conventions).
• Server Actions accepting mass-assigned fields (because they didn't know what a Server Action is).

These are tools designed for a pre-AI world. They look for OWASP Top 10 instances in well-defined frameworks. They were not designed to know that useFormState + "use server" is a new attack surface.

What we built

VibeWShield scanners encode the AI-coding attack patterns directly. When it sees Next-Action headers, it knows to enumerate Server Actions. When it finds a supabase.co URL in a JS bundle, it extracts the project ref and tests RLS on common table names. When it sees isAdmin in JS source, it also tries /api/admin/* without a session.

The 65+ modules are opinionated. We chose coverage over neutrality — better to have a Lovable-specific scanner that emits false positives occasionally than a generic tool that misses 80% of the real issues.

Who we are

A small team from security consulting and product engineering backgrounds. We've shipped real apps, scanned real apps, and fixed real bugs. VibeWShield is what we wish existed when we started reviewing AI-generated code.

Where we're going

The catalog grows when we see new patterns. tRPC scaffolding with public procedures, shadcn/ui HTML injection, Convex auth gaps, Next.js parallel-route authorization holes — each new scanner is a one-file change in the orchestrator and a handful of tests.

If your app is in a framework or stack we don't cover well yet, email us. We'll usually have a module for it within two weeks.