VibeRaven

VibeRaven VibeRaven checks AI-built apps on Vercel + Supabase for launch gaps before you ship: tables without RLS, permissive policies such as using (true) , service_role keys in client code, anon-callable security definer functions, the wrong pooler port and unverified Stripe webhooks. Run npx -y viberaven@1.7.6 check in your app's folder. It reads the repository on your machine, needs no account, and names the file and line for each gap.

Website · What it checks · When to use it · How it compares · Local Studio · Agent skills · Releases

Quick start

Requires Node.js 20 or newer. From your app's project root:

npx -y viberaven@1.7.6 check

• In a terminal or CI: npx -y viberaven@1.7.6 check
• For coding agents: npx -y viberaven@1.7.6 check
• Windows PowerShell: use npx.cmd if npx is blocked by the execution policy.
• In a coding agent you can also just ask: "check this with viberaven".

It reads supabase/migrations, your client and server code, package.json and .env.example. It does not connect to your Supabase project or send requests to your app. It exits 1 when it finds a blocker, so it also works as a CI step.

What it checks

Two other Security Advisor lints come up often in the same apps. VibeRaven has no rule for them yet, and the guides explain the fix:

• security_definer_view: what it means and how to fix it
• function_search_path_mutable: what it means and how to fix it

For a before-and-after run on one migration, see the missing-RLS example.

Example output

Historical output from viberaven check 1.7.2 on a synthetic Next.js + Supabase app with one of each gap (project path shortened):

viberaven check · ~/my-app

🔴 No RLS policy proof in migrations (rls_disabled) 1 public table without row level security: public.profiles (supabase/migrations/20260301000000_init.sql:1). The Data API does not enforce row restrictions for roles and operations allowed by the table's grants. Verify those grants to determine who can read or change rows. 🔴 A policy lets anyone write every row (rls_policy_allows_all_write) Policy "orders are editable" on public.orders (supabase/migrations/20260301000000_init.sql:13) lets anyone, signed in or not, update every row, to any values: using (true). 🔴 Service role key used in client code (service_role_key_in_client_code) app/admin/page.tsx:4: reads NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. NEXT_PUBLIC_* variables are exposed to client code by Next.js, and the service role key skips RLS entirely. Move the call behind a server route or edge function and rotate the key. 🟡 Security definer function callable by the Data API roles (security_definer_function_executable) public.grant_credits(uuid, integer) at supabase/migrations/20260301000000_init.sql:15 is security definer, so it runs with its owner's rights and RLS does not limit what it touches. No migration revokes EXECUTE from public, anon, authenticated, so anyone holding the anon key can call it at /rest/v1/rpc/grant_credits. If only the server calls it, add: revoke execute on function public.grant_credits(uuid, integer) from public, anon, authenticated; Fix: revoke execute on function public.grant_credits(uuid, integer) from public, anon, authenticated; 🟡 Stripe webhook does not verify the signature (unverified_stripe_webhook) 1 Stripe webhook handler without signature verification over the raw body: app/api/stripe/webhook/route.ts (no signature check (constructEvent), no stripe-signature header, no raw body). Anyone who finds the URL can post a fake event, for example a paid checkout. 🟡 Env vars used in code but missing from .env.example (env_var_drift) Code reads 1 environment variable that .env.example does not document (NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY). Fresh clones, CI, and the production deploy can silently run without them. 🟡 Database queries with no row limit (unbounded_query) 1 file run Supabase selects or Prisma findMany with no .limit()/.range()/take bound (app\admin\page.tsx). These work with 50 test rows and melt with 50,000 production rows. ⚪ No error monitoring detected (missing_monitoring) No Sentry/PostHog (or similar) instrumentation was found. Production errors will only surface when users complain.

Verdict: ❌ 3 blockers, 4 warnings · score 5 Fix: viberaven fix · Details: ~/my-app\.viberaven\agent-tasklist.md Optional live catalog: npx -y viberaven@1.7.6 live start --provider supabase --project --json (read-only metadata; account required; server availability not checked; user approves in the browser and approves the project read). Keep checks running with your agent: npx -y viberaven@1.7.6 init

Every result also lands in .viberaven/ as markdown and JSON (agent-tasklist.md, gate-result.json, context-map.json), so a coding agent and your git history can read it.

When to use it, and when not to

Use it:

• before you launch or hand off a Vercel + Supabase app built with Lovable, Bolt, Cursor, Claude Code or Codex;
• after a Supabase migration or a policy change;
• when a production error points at RLS, the service_role key, env vars, the database connection or a Stripe webhook;
• on every push or pull request, through the GitHub Action below.

It is not the right tool when:

• You need to know what is live in the database. VibeRaven is a repository check, not a live database test. It reads migrations, so it cannot see a policy someone added in the Supabase dashboard. Use Supabase Security Advisor for the live project.
• You need a full security audit. It does not send requests to your app, test for XSS or CSRF, or look up dependency CVEs. A clear result is not a security audit.
• You need to know the app works. It does not run your build or click through your pages. Use Playwright or your own tests.
• The app does not use Supabase. Most of the checks have nothing to read.

How it compares

These tools answer different questions, and most launches need more than one of them.

Data: 512 public Lovable apps

We ran the check on the Supabase migrations of 512 public Lovable repos. From the write-up:

In a static read of 512 public Lovable projects on GitHub with a supabase/migrations folder (October 2026), 47.3% (242) define at least one security definer function in the public schema that a signed-out caller with the anon key can run at /rest/v1/rpc.

The post has the method, the limits and the fix. An earlier post covers RLS policies in the same 512 apps.

Fix the gaps

npx -y viberaven@1.7.6 fix                         # list gaps with safe automatic recipes

npx -y viberaven@1.7.6 fix --gap --dry-run # preview one recipe npx -y viberaven@1.7.6 fix --gap # apply it npx -y viberaven@1.7.6 audit --vercel-supabase # RLS in migrations, pooler port, service_role key npx -y viberaven@1.7.6 --strict # the verdict as an exit code for CI (exit 1 on not_clear; warnings exit 0)

The rls_disabled recipe adds a mig