SCAN YOUR ONLOOK APP FOR VULNERABILITIES

Onlook is the “Cursor for designers” — an open-source visual editor where you manipulate the rendered page and Onlook writes the Next.js + TailwindCSS code underneath, with hosted builds and Supabase commonly handling auth and data. The output is standard, inspectable Next.js in a real repo, which is a genuinely better starting position than closed platforms. The catch: the workflow never requires anyone to read the code, and the person shipping is often a designer working entirely in the visual layer.

“It’s design edits, not backend code” is the trap. Every visual edit is a code change, and Next.js is a framework where the server/client boundary, route handlers, server actions, and middleware each have their own quiet way of going wrong. The recurring shape we see: the page looks perfect and gated, and the API behind it is wide open — because the visual layer implies security the generated layer never enforces.

VibeEval scans the deployed app from outside, attacking the Next.js and Supabase layers the visual editor doesn’t show.

Common vulnerabilities we find in Onlook apps

The recurring shapes in visually-built Next.js + Supabase apps, and how each one gets exploited.

Secrets crossing the server/client boundary

Anything imported into a "use client" component or prefixed NEXT_PUBLIC_ ships to every visitor’s browser. AI edits under “make it work” pressure move a fetch client-side — taking the key with it — or add the NEXT_PUBLIC_ prefix to silence a build error. The exploit: grep the deployed bundle for sk_live, sk-proj-, or an eyJ service-role JWT. Fix direction: read secrets only in server components, route handlers, and server actions, and rotate anything that ever shipped — the Token Leak Checker checks the bundle from outside.

Route handlers without auth

Generated app/api/*/route.ts handlers frequently ship without a session check. Middleware gates the pages, so everything looks protected in the browser — but curl https://yourapp.com/api/orders answers anyone, no session required. The middleware matcher is usually the accomplice: it covers /dashboard/:path* and skips /api/*, and matcher gaps fail open. Fix direction: resolve the session at the top of every handler and return 401 when absent; treat middleware as defense-in-depth, never the only gate.

Missing ownership checks (BOLA)

Auth says “some logged-in user,” not “the user who owns record 42.” Generated CRUD looks up by ID and returns whatever it finds: sign in as user B, replay user A’s request with A’s record ID, and the handler hands over A’s data. This is the most common exploitable finding in AI-generated Next.js apps — see BOLA in AI-generated CRUD. Fix direction: scope every query to the session user (.eq("user_id", user.id)) or enforce the same in RLS, and verify with the two-account test.

Server actions treated as internal functions

A server action compiles to a public HTTP endpoint; the form “calling” it is not an access control. Generated actions skip validation and auth because they were “only called from one form” — and an action that spreads its input into an update accepts { role: "admin" } too (mass assignment). Fix direction: every action starts with a schema parse that allowlists fields, then a session and ownership check — the same standard as a route handler.

Supabase RLS gaps

The anon key in the browser is safe exactly as long as Row Level Security holds on every table. The pattern that breaks it: the first tables get policies, the table added in week three doesn’t, and the anon key reads it directly — no application bug required. A select-only policy also leaves writes open. Fix direction: enable RLS per table with auth.uid()-scoped policies for select, insert, update, and delete; the Supabase RLS Checker verifies from outside. The service-role key bypasses RLS entirely and must never reach the client.

Source maps and unreviewed visual edits

Production source maps ship your original TypeScript — comments, TODOs, internal logic — to anyone who asks; confirm productionBrowserSourceMaps stays off and .map requests 404, per source maps and exposed .git. The deeper Onlook-shaped risk is process: visual edits produce code diffs nobody reads, so a removed auth check or a new NEXT_PUBLIC_ var deploys silently. Fix direction: deploy from a protected branch and have a React-literate reviewer skim diffs touching app/api/, actions, middleware, and env usage.

How VibeEval works with Onlook

1. Enter your deployed URL. Point VibeEval at the Onlook-hosted deployment or wherever the Next.js app runs — no repo access needed, exactly what an attacker sees.
2. The agent attacks the app in a real browser. It maps pages, app/api/ routes, and server-action endpoints, then probes them: session-stripped requests, two-account BOLA replays, mass-assignment payloads against actions, direct Supabase queries with the bundled anon key to test RLS, bundle checks for leaked keys, and header and source-map checks.
3. Read the report, paste the fixes. Findings arrive ranked by severity, naming the route, action, or table affected — each with a paste-ready fix prompt you can drop into Onlook’s AI chat for one-shot remediation.

Manual testing vs VibeEval

	Manual review	VibeEval
Time per full pass	Hours: open every route.ts, every action, middleware.ts, and the RLS policy list	Minutes, run against the deployed URL
Cross-user (BOLA) coverage	Two-account replay by hand — high effort, so it gets spot-checked	Attempted on every discovered ID-keyed route, action, and table
RLS verification	Reading policies in the Supabase dashboard, table by table	Tested from outside with the anon key, the way an attacker would
After each edit session	Requires a diff reader — the exact step the visual workflow skips	Re-scan on demand; a dropped auth check surfaces as a new finding
Business-logic flaws	Where human review wins — workflow abuse, pricing rules	Out of scope; the scanner frees review time for exactly this
Cost	Engineer-hours per deploy, from people the workflow was built to not need	Flat, repeatable after every visual edit

The honest framing: Onlook’s advantage is that everything is standard, reviewable code — someone should still review it. The scanner wins on repeatability, giving every designer-shipped deploy the same security pass without an engineer in the loop each time.

Frequently asked questions

Does VibeEval have special support for Onlook?

Yes. VibeEval recognizes the Next.js + Supabase patterns Onlook produces — route handlers, server actions, middleware matchers, RLS-backed tables — and runs the probes specific to that stack: session-stripped API calls, anon-key table enumeration, action mass-assignment, and boundary leak checks.

Can I scan during Onlook development?

Deploy to a staging or preview URL and scan there before promoting to production. Since Onlook projects are real Next.js repos, the same build you scan is the build you ship — fix the findings, redeploy, and re-scan to confirm.

Can designers safely ship code with Onlook?

Yes, with a gate. The platform’s point is that non-engineers ship real code changes, which also means changes land that nobody security-reviews. Keep the project in git, deploy from a protected branch, have someone skim diffs touching app/api/, actions, and env usage — and use the scanner as the automated check on every deploy in between.

What authentication issues are common in Onlook apps?

Route handlers without session checks, middleware matchers that cover pages but not /api/*, server actions callable without auth, RLS policies scoped to “any authenticated user” instead of the owner, and OAuth redirect URLs left open to dev domains. The pattern underneath all of them: the visual layer looks gated, the layer behind it isn’t.

How does Onlook security compare to other AI app builders?

Onlook outputs standard, inspectable Next.js in a real repo — a structural advantage over closed platforms, since everything can be diffed, reviewed, and scanned. But the visual workflow means code often ships unreviewed, so the same auth, RLS, and secret-exposure findings appear as elsewhere. The safety analysis covers the trade-off in depth.

Related Onlook resources

• How to Secure Onlook — the step-by-step hardening checklist: boundary audit, handler auth, RLS, actions, middleware.
• Is Onlook Safe? — in-depth analysis of the Onlook generation pattern and the six areas to harden.
• Onlook Security Checklist — severity-ordered pre-launch checklist, including the after-every-edit-session routine.
• Supabase RLS Checker — free outside-in check that every table actually enforces RLS.
• Token Leak Checker — free check for secrets that crossed into your deployed bundle.

Test your Onlook app before launch

The visual editor shows you the page; it cannot show you the open route behind it. Run a scan against your deployed URL, paste the fix prompts back into Onlook, and ship the version where the API is as protected as the UI implies.