If your vibe app is live on Vercel or was built with Lovable, you are working with two platforms that have had documented security incidents or vulnerability patterns in the past year. This article gives you a specific, ordered checklist for each — no theory, just the steps. Work through them in order. Most take under ten minutes each.
Start with credentials, because credential exposure is the fastest path to a serious breach and the easiest to check. Open your app in a browser, open the developer tools, and navigate to the Sources or Network tab. Search for common patterns: long alphanumeric strings that start with "sk-", "AKIA", "ghp_", or "supabase". Check your JavaScript bundle files. If you find any key that grants meaningful access to an external service, it needs to come out of client-side code immediately and be moved to a server-side environment variable. For Vercel apps, environment variables belong in the project settings panel under Environment Variables, set to the appropriate scope (Production, Preview, Development). For Lovable apps connected to Supabase, the anon key can stay in client code only if Row Level Security is enabled — without RLS, it is equivalent to a master key.
For Vercel specifically, the next step is auditing environment variable scope. Open your Vercel dashboard, navigate to each project, and open the Environment Variables settings. Review every variable: does it need to be available in Preview deployments, or only in Production? Preview deployments are accessible via public URLs and are often shared with external reviewers. If a production database URL, payment secret, or third-party API key is scoped to Preview environments, it is exposed to anyone who receives a preview link. Change production secrets to Production scope only.
Still on Vercel: check your team membership and integration access. Go to team settings and look at who has access. Look at which third-party integrations are authorized. Remove any members who should not have access. Revoke OAuth grants for integrations you no longer use. Vercel's audit log, in the team settings panel, shows access events with timestamps — scan it for any unusual activity, particularly around environment variable reads or deployment triggers from unfamiliar IP addresses or actors.
For Lovable apps, the Supabase configuration check is the highest-priority step. Log into your Supabase dashboard and navigate to the Authentication settings, then to the table permissions under Table Editor. For each table that contains user data or sensitive information, verify that Row Level Security is enabled. Then check the RLS policies: there should be at least one policy on each table that restricts which rows a given user can read or write. If RLS is disabled on any table that holds real data, enable it before doing anything else. A disabled RLS setting on a Supabase table means anyone with your anon key — which is anyone who has visited your app — can read and write every row in that table.
For both platforms, check your CORS configuration if your app has an API. Permissive CORS settings ("allow all origins") mean any website can make authenticated requests to your endpoints using a visitor's credentials. If your API endpoints require authentication, restrict CORS to your own domain. If your endpoints are genuinely public, permissive CORS is acceptable, but document that decision explicitly so it is not changed accidentally.
Check your authentication flows. If your app has any pages or actions that should require a logged-in user, test them while logged out. Open an incognito window and navigate directly to the URL of a protected page or API endpoint. If you can access it without logging in, you have a missing authentication check. For Vercel apps, this means adding auth middleware or guards at the route level. For Lovable apps using Supabase Auth, it means verifying that every Supabase query that accesses user-specific data uses the authenticated client, not the anonymous client.
Once you have addressed the above, set a reminder to rotate your production secrets every ninety days. Add this to your calendar now. Key rotation sounds like overhead until you discover a leaked credential — at that point, teams that rotate regularly can determine with confidence exactly how long a leaked key was valid. Teams that never rotate have no such bound. For Vercel, the rotation process is straightforward: update the environment variable value in the project settings, trigger a redeployment, then revoke the old key in the issuing service. For Supabase, you can cycle your service role key from the API settings panel — note that the anon key is tied to your project and cannot be rotated without migration.
Finally, upload your app to VibeClub and run the automatic security scan. The scan fetches your source files via the GitHub API, checks for hardcoded secrets and dangerous code patterns, scores the risk, and stores the result with your app record. It is not a substitute for the manual checks above, but it catches the most common machine-detectable issues in seconds and gives you a documented baseline you can point to when sharing or selling the app. A green scan result is not a security guarantee, but a red one is a clear signal that something needs attention before the app goes wider.