Securing a vibe-coded app: 7 mistakes to fix before you publish

Your app works. The form saves, the page displays, the button exports. That doesn’t mean it’s safe. An AI coding tool answers exactly what you asked for, not “make sure no one else can read other users’ data” if you never actually said so. Here are the seven mistakes that show up most often in vibe-coded apps, and the fix for each one.

Why this can’t wait

In late September 2026, an investigation found around 16,000 Supabase databases leaking personal data (names, addresses, passwords) because of misconfigured applications. A few months earlier, a researcher had already documented CVE-2025-48757: more than 170 applications built with the Lovable tool exposed their entire database to anyone, without even logging in, because of a single missing setting. These aren’t isolated cases: they’re configuration mistakes that keep recurring, because the same AI tools scaffold projects the same way every time.

These seven families of flaws are common enough that they map, one by one, to categories in the OWASP Top 10:2025, the world’s reference list of web security risks, updated in 2025 with two new categories, one of them dedicated specifically to software dependencies.

Why a student project is just as exposed as a startup

You might think these seven mistakes mostly matter to companies handling thousands of customers. In practice, a student project often checks every box that exposes it: a public GitHub repository to show off your work in a portfolio, a link shared widely on a school Discord or a class group chat, a demo shown off at a hackathon. None of that is a problem by itself, but it means your project can be viewed, tested, and sometimes attacked by far more people than the handful of classmates you had in mind when you published it. The fixes below don’t require any more skill than the rest of the project; they just require handling them before you share the link, not after.

The 7 mistakes, and how to fix each one

1. A secret API key exposed in the browser. A key meant to stay secret (database, paid service, AI provider) ends up written in plain text inside the JavaScript sent to the browser. Anyone can pull it out in three clicks using the browser’s developer tools. Fix: a secret key should never leave your server. Always distinguish a public key (“anon” or “publishable,” meant to be visible) from a secret key (“service_role” or “secret,” which must stay server-side only, inside a backend function).

2. A committed .env file. The file holding your keys travels with the rest of your code on the first git push, often to a public repository. GitGuardian’s 2025 State of Secrets Sprawl report counted more than 23.8 million new secrets exposed on public GitHub in 2024, a 25% increase over the year before. Fix: add .env to your .gitignore before your first commit, not after. If a secret has already been pushed, treat it as compromised and regenerate it; removing it from history isn’t enough, you have to rotate it.

3. A database with no Row Level Security (RLS). On Supabase (the database most vibe-coding tools default to), the official documentation is blunt: “a table in an exposed schema without RLS is readable and writable by any role with a grant on it.” That’s exactly the root cause of CVE-2025-48757: Supabase disables RLS by default on every new table, and the code these tools generate never turned it on. Fix: enable RLS on every table (alter table my_table enable row level security;) and write one policy per operation, for example so a user only ever sees their own rows:

create policy "Everyone sees only their own data"
on my_table for select
to authenticated
using ( (select auth.uid()) = user_id );

4. Homemade authentication. Writing your own password handling, sessions, or tokens from scratch instead of using a proven system. This falls under the “Authentication Failures” category of the OWASP Top 10:2025. Fix: use the authentication system your platform already provides (Supabase Auth or equivalent) instead of inventing your own. Rolling your own is almost never faster, and it’s far riskier.

5. No input validation. Trusting whatever a form or API request sends, without ever checking its format, size, or content. This is the “Injection” category of the OWASP Top 10:2025, historically one of the most exploited. Fix: validate and sanitize every input on the server side (not just in the browser, which can be bypassed), and use parameterized queries instead of building SQL by string concatenation.

6. Wide-open CORS. An API configured to answer any website (Access-Control-Allow-Origin: *), which lets a malicious site call your API on behalf of a logged-in user. This is a textbook example of the “Security Misconfiguration” category in the OWASP Top 10:2025. Fix: explicitly allow a precise list of trusted domains, and never reflect the visitor’s Origin header straight back in your response.

7. Vulnerable dependencies. Installing packages without ever checking whether they carry known vulnerabilities. The OWASP Top 10:2025 created a dedicated category for this, “Software Supply Chain Failures,” expanding the old 2021 “vulnerable and outdated components” category, a sign the topic is now considered even more critical than before. Fix: run npm audit (or your language’s equivalent), which, per npm’s official documentation, “submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities.” Keep a lockfile (package-lock.json) and update regularly.

A pre-publish checklist

Before you share your project’s link, check, in order:

• No secret key appears in the code sent to the browser (inspect the source your browser actually shows, not just your own files).
• .env is in .gitignore, and no secret is sitting in your Git history.
• RLS is enabled on every table in your database, with at least one tested policy.
• You’re using an existing authentication system, not your own.
• Every form and every API route validates its input server-side.
• Your API only allows the domains you actually need.
• npm audit (or equivalent) shows no unfixed critical vulnerability.
• No secret shows up anywhere in your repository’s Git history, even in an old commit you think you’ve since “fixed.”
• You’ve tested the app with a second account to confirm it never sees the first account’s data.

Key takeaways

• An app that “works” on screen can still be exposing every user’s data: the visual test isn’t enough.
• The seven most common mistakes each map to a recognized category in the OWASP Top 10:2025.
• The most documented flaw in vibe-coding tools is missing Row Level Security on Supabase: turn it on for every single table, systematically.
• A secret key that was committed or shipped to the browser needs to be regenerated, not just deleted.
• If your project handles real personal data, even a classmate’s, treat it with the same seriousness as a professional one.

For a guided check of these seven points on your own project, the securite-app-vibe skill walks through this checklist step by step.