Vibe-Coded App Security Holes to Close Before Real Users

Vibe-coded app security holes are the gaps your AI builder left open while making the app work. Before real users sign up, close four of them: open database tables, secrets in front-end code, auth checks that point the wrong way, and production settings never switched on. The problem: it works, and it is wide open Your app works. You typed what you wanted, the AI tool built it, and it looks right. People can sign up, add details, and pay. So the question is simple: can anyone else read all of it? In June 2026, Symbiotic Security scanned 1,072 vibe-coded apps using Supabase. 98% had at least one flaw, 16% a critical one, and only 26 were clean. On 172, anyone could delete records without signing in; on 39, anyone could read every table. UpGuard reported the same pattern on 25 September 2026: 16,326 Supabase databases had tables readable from the public internet with no sign-in, out of roughly 300,000 domains scanned, and over half showed signs of personal data inside. Why it happens An AI builder aims for a working demo, not a locked door. It writes the feature, watches it run, and moves on. Security checks are not part of that loop unless you ask for them. Tables are the clearest example. One made in the Supabase dashboard gets Row Level Security switched on by default; one made with raw SQL does not, and raw SQL is how AI tools make tables. UpGuard traced the open databases back to exactly that gap. Keys follow the same pattern. The tool needs a key to talk to the database, so it pastes the key into the code where it can reach it — code that ships to the browser, where anyone can copy it out. In the Symbiotic scan, 308 apps had their Supabase key in their JavaScript, and 24 had another API key in their source code. Auth guards get written the wrong way round too. In February 2026, The Register reported on one Lovable-built education app with 16 vulnerabilities, six critical, that exposed 18,697 user records including 14,928 unique email addresses. Missing RLS and inverted auth guards were the cause: the checks existed, but they let the wrong people through. Vibe-coded app security holes: the minimum fix Work through these in order. Each step takes minutes, and each closes a hole the scans above keep finding. List every table with Row Level Security switched off. In the Supabase dashboard, check each table in the public schema, or run this query: select tablename from pg_tables where schemaname = 'public' and rowsecurity = false; Every table that shows up is readable by anyone with your public key if your project uses the old automatic grants (all projects created before 30 May 2026 do). Switch RLS on for each one, then write policies that only let a signed-in user touch their own rows — one each for read, add, change, delete. Do not write a policy that says using (true): it switches RLS on and lets everyone through — the same as having no RLS at all. It is also the fix an AI assistant writes most often when a query fails, so check for it even if RLS looks on. Search your code for every key, then sort them into two piles. The publishable key, sometimes called the anon key, is designed to be public, so it can stay in front-end code. Your data is protected by RLS policies, not by hiding that key. The service_role key, and any key labelled secret or private, must never sit in front-end code: it bypasses RLS. Move anything needing one behind your own server or a server function, and rotate every key that was ever in client code — the old key is already out there, in every copy that shipped. Do not just move a secret key into a different file in the same front-end folder: the browser still downloads that file, so the key is still public. Test every action while signed out. Open a private browser window and try to read, change, and delete a record without signing in. If any of it works, the guard is missing or backwards. Check the admin pages and API endpoints too, not just the screens users see. In a March 2026 VibeWrench scan of 100 vibe-coded apps, 21% had no authentication on their endpoints. Check storage too: a public bucket serves every file to anyone with the link. Switch on the production protections, then re-check after every change. Turn on CSRF protection: 70% of the VibeWrench apps were missing it. Run the Supabase Security Advisor and fix every RLS warning it lists. Then repeat this check after each round of AI changes: each fix can quietly reopen a hole. The holes come back when nobody is watching. When to get help instead Get help if a service_role key was ever live in shipped code, or if your checks show records already readable. Get help too if you cannot tell which tables are open, or if your policies still let a signed-out test read them. Guessing at access rules is how the holes stay open. If this is your app, contact me through https://israr-kundi.web.app