Ubserve vs ScanVibe: Which Vibe Coding Scanner Finds What Matters

I Ran Both Scanners on the Same App — Here Is What Each Found

If you are evaluating a vibe coding security scanner for an AI-built app, the most important question is not what the scanner costs — it is what the scanner actually checks. ScanVibe and Ubserve target different layers of the same problem.

I ran both on a Lovable-built app with a Supabase backend. ScanVibe completed in under 15 seconds. It flagged a missing X-Frame-Options header and a Supabase URL visible in the JavaScript bundle (expected — it is the public anon URL, but the scanner correctly notes it). That was the full finding set.

The Ubserve scan ran for two minutes. In addition to the header finding, it flagged that two of the app's three Supabase tables had RLS enabled but with policies using auth.role() = 'authenticated' rather than user_id = auth.uid() — meaning any authenticated user could read any row. It also flagged a server action with no authentication check.

ScanVibe saw the same header issue. It did not — and could not — see the RLS policy logic or the unprotected server action. Both are invisible from outside the deployed URL.

That is the structural difference this comparison explains.

TL;DR

ScanVibe checks what your deployed URL exposes to the outside world: SSL, headers, visible API keys, accessible files, basic CORS.

Ubserve checks what the outside world cannot see: whether your Supabase RLS policies are correctly scoped, whether your API routes verify resource ownership (not just session existence), and whether your service role key is reachable from client code through import chains.

The three documented vibe coding breaches in 2025–2026 — Moltbook (no RLS), Lovable (BOLA), Base44 (auth bypass) — were all invisible to URL-based scanners. You cannot detect a missing auth.uid() in a policy by scanning a URL. You cannot detect BOLA by scanning a URL. These require a different approach.

What Each Scanner Actually Checks

Why URL-Based Scanning Has a Structural Limit

ScanVibe is a passive DAST scanner. DAST — dynamic application security testing — means it interacts with your live application as an external user would. This is genuinely useful and catches real issues. Exposed keys in your JavaScript bundle, missing security headers, publicly accessible .env files: these are all real vulnerabilities and ScanVibe finds them reliably.

The structural limit: a DAST scanner cannot see anything that requires code access or an authenticated session with intentional data access.

Consider the Moltbook RLS failure. ScanVibe could tell you whether RLS is enabled on a Supabase table — because Supabase exposes that information in its API. What it cannot tell you is whether the policies on that table correctly reference auth.uid(). Our Supabase security checklist shows exactly what the correct policy looks like. The difference between these two policies:

-- ScanVibe sees: "RLS is enabled" ✅
CREATE POLICY "read own records"
ON user_data FOR SELECT
USING (auth.role() = 'authenticated');
-- ^ This exposes all users' data to any authenticated user
-- ^ A URL-based scanner sees: RLS enabled. No finding.

-- The correct version
CREATE POLICY "read own records"
ON user_data FOR SELECT
USING (user_id = auth.uid());
-- ^ This correctly restricts access to the row owner

Both policies show "RLS enabled" to an external scanner. Only one is actually secure. Detecting this requires reading the policy definition — which requires Supabase admin access, not a URL scan.

The same logic applies to BOLA. A URL-based scanner can tell you an endpoint requires authentication. It cannot tell you whether that endpoint correctly scopes data to the authenticated user. That check requires reading the handler code and verifying the query includes a WHERE user_id = [session.user.id] constraint.

When ScanVibe Is the Right Starting Point

If you have never run a security scan on your vibe-coded app, ScanVibe is a reasonable first step. It is free, fast (under 15 seconds), and will immediately surface any obviously exposed keys, missing headers, or accessible sensitive files.

Concrete scenarios where ScanVibe is the right tool:

• You built a prototype and want a quick external check before showing it to people
• You want to confirm your security headers are configured before a demo
• You want a fast check after a deployment to catch any obvious regressions
• You need a PDF report for a basic compliance conversation

ScanVibe's monitoring feature (Pro, $9/month) with Slack/Discord webhooks is a useful addition for teams who want to catch header regressions or new exposed files across deploys without running scans manually.

When You Need to Go Beyond ScanVibe

The three vibe coding breaches that made headlines in 2025–2026 were all invisible to external scanners:

• Moltbook: RLS was technically configurable via external API, but the policy logic was wrong. External scanner result: no finding. Actual state: 1.5 million tokens exposed.
• Lovable: The endpoint required authentication. External scanner result: endpoint requires auth, no finding. Actual state: any authenticated user could access any other user's data.
• Base44: Authentication existed. External scanner result: auth detected, no finding. Actual state: authentication was bypassable via undocumented endpoints.

All three incidents are covered in detail in our vibe coding hacks breakdown. The Base44 security guide covers the platform-level risk specifically.

If your app handles user data — any data that belongs to one user and should not be accessible to another — you need authorization checks that go deeper than what is visible from the outside.

Scenarios where ScanVibe's scan scope is insufficient:

• Your app stores user data in Supabase and you have not verified every policy references auth.uid()
• Your app has API routes that return user-owned resources and you have not tested whether a different user can request those same resources
• Your app uses the Supabase service role key anywhere in your codebase and you have not confirmed it is isolated to server-only files
• Your app was built by Lovable, Bolt, or Cursor and you have not audited the authorization layer since launch

Use the pre-deploy security checklist to run through every authorization pattern before your next production deploy.

How to Run Both in Sequence

The most thorough approach for a vibe-coded app before launch:

1. Run the free Ubserve scan — covers the same frontend layer as ScanVibe plus additional checks (takes 2 minutes, no signup required)
2. Fix any frontend findings — exposed keys, headers, accessible files
3. Run the Ubserve full audit — extends into RLS logic, API authorization, and service role boundaries
4. Fix the deeper findings — these are the ones that caused the documented breaches

The free scan at ubserve.com/scan covers SSL, headers, key exposure in your frontend bundle, and your security score. If your score is above 90 with no critical findings, the frontend layer is clean and the audit will focus on the code and architecture layer.

Pricing Comparison

The Bottom Line

ScanVibe and Ubserve scan different things. They are complementary, not interchangeable.

ScanVibe tells you what an attacker can see from the outside. Ubserve's full audit tells you what an attacker can do once they are inside — which is the layer that caused every documented vibe coding breach.

Run the free Ubserve scan. If your app has any of the patterns from this guide, the scan will find them before your users do.

See also: our comparison against VibeAppScanner and the full vibe coding security risks guide.