Vibe coding security best practices and AI tool privacy

AI-written code usually works on the first try, and that is the problem: it looks finished while skipping the security steps a human developer adds by habit. In one Lovable-hosted app, a researcher reported 16 vulnerabilities, six of them critical ^[1]. None of that required an exotic AI-specific bug. It took ordinary missing protections that nobody checked for.

When you prompt an AI to build a feature, it optimizes for the feature. Access checks, secret handling and input validation only show up if you ask for them or review for them. A checklist built for vibe coding makes those steps routine.

Three habits prevent most of the damage: review the code, keep secrets out of it, and don't let the AI invent your authentication. As one vibe coding guide puts it, check the code the AI gives you the way you would proofread an important email ^[2].

1. Review before you merge. Read each diff, not just the result in the browser. Pay extra attention to anything that reads or writes user data, handles payments, or decides who can see what.
2. Never hardcode secrets. API keys and passwords do not belong in your source files ^[2]. AI tools often paste a key straight into the code to make a demo work, so search for them before every commit.
3. Use proven authentication. Choose an established library such as NextAuth instead of AI-generated login code ^[2]. Session handling, password storage and token checks are easy to get subtly wrong, and those mistakes rarely show up while you test the happy path.

When you ask the AI for a change, ask it to explain the security implications too. That won't replace your review, but it brings up things worth checking.

Anything that ships to the browser is public, so credentials and sensitive logic must live on the server. Replit's own vibe coding checklist tells users to store API keys and other sensitive information in Replit Secrets ^[3], and most hosting platforms offer a similar secrets store.

• Keep keys server-side. If the frontend needs data from a paid API, route the request through your own backend so the key never reaches the client. Watch for environment variables that your framework exposes to the browser by prefix.
• Never commit keys to the repo. Add your local environment file to `.gitignore`. If a key was ever committed, rotate it, because deleting it from the latest version does not remove it from Git history.
• Check permissions on the server for every action. Hiding a button in the UI doesn't stop anyone from calling the endpoint directly. Each request that reads or changes data should confirm the user is allowed to do it.
• Protect state-changing requests. Forms and requests that change data should carry CSRF protection, so another site can't trigger actions on behalf of a logged-in user.

No AI coding tool is private by default across every plan. What happens to your code depends on the specific tool, its settings and your plan tier. Cursor says it holds a SOC 2 Type II attestation and commits to at-least-annual penetration testing by reputable third parties ^[4]. Under commercial terms, Anthropic does not train models on code or prompts sent to Claude Code unless the customer opts in ^[5].

The details matter. Cursor's Privacy Mode means the company will not train on your data when it is enabled ^[4], so you need to confirm it is switched on for your account. On consumer Claude plans, Anthropic gives you the choice to allow your data to be used for model improvement ^[5], so check that setting rather than assuming. A SOC 2 attestation describes a company's security controls. It is not a guarantee of GDPR, HIPAA or any other legal compliance.

The Z.ai case is the clearest warning. Its ZCode tool packaged local project data and attempted to send it to cloud storage without clear user consent ^[6]. One upload was a 313MB encrypted archive containing a snapshot of a commercial project and its Git history ^[6]. Z.ai then disabled the workflow that generated and uploaded those repository snapshots ^[6], though independent assessments of the fix had not been fully published at the time of reporting.

The practical rule: read the data policy for your exact plan, turn on any privacy setting it offers, and keep secrets out of your repository so that a tool that does upload your project has less to leak.

One vibe-coded app on Lovable exposed 18,697 user records, and 14,928 of them contained unique email addresses ^[1]. The researcher behind the report found 16 vulnerabilities in that single app, six of them rated critical ^[1].

The lesson isn't that one platform is uniquely unsafe. Any app built fast, with no one checking who can read which data, can end up the same way. The basics in this guide (server-side access checks, protected secrets, proven auth and a test before launch) target exactly that kind of failure. If your app stores user data, test it as an attacker would before you share the link.

The safest way to test a hosted vibe-coded app is to scan a copy, not your live production site. If you build on Lovable, Replit, Base44, Vercel or a similar platform, clone or fork the project and give BattleTester the cloned or preview URL, so the scan runs on the copy.

You can start with a free surface scan, and no credit card is required upfront. If you want a deeper look, the full pentest costs $15 and is charged only if the scan finds High or Critical vulnerabilities. If it finds none, you pay nothing and the report stays fully accessible. Reports end with AI instructions you can hand to your coding agent to fix the issues it found.

If you build on Replit, see whether Replit has a built-in security scanner and how it compares with testing the running app.

Security headers are a quick fix that vibe-coded apps often lack, because the AI rarely adds them unless you ask. Headers such as `X-Frame-Options`, `X-Content-Type-Options` and `Strict-Transport-Security` (HSTS) tell the browser to block framing, stop content type guessing and always use HTTPS. Most hosting platforms and frameworks let you set them in one config file.

If you're new to them, start with what security headers mean and why they matter. To check a site quickly from your browser, see which security headers extension to use and what it misses.

Be clear about limits. BattleTester is not a comprehensive security audit and does not replace a professional security assessment by qualified security professionals. If your app handles payments, health data or other sensitive information at scale, bring in a professional auditor before launch.