Is your AI-built app safe to put in front of customers?

A working app is not the same as a safe app.

If you built something with Lovable, Replit, Bolt, v0, Base44, Cursor, or Claude Code and you are thinking about sharing it with real users, this guide is for you. There are specific things to check before you invite anyone in. Most are not complicated to verify — but they are easy to skip, and the consequences of skipping them range from embarrassing to expensive.

The short answer

A vibe-coded app can absolutely be safe enough to share with real users — but only after you have verified a short list of things that AI app builders do not automatically handle for you. The most common failure is not the code itself. It is configuration: who can see the app, where the secrets are stored, whether the database enforces access rules, and whether someone other than the author can manipulate their own account. Check those four areas first. If anything is unclear, that is the moment to get a second set of eyes.

Quick-triage table: safe to share, risky, or do not ship yet

Use this before you send anyone a link. You do not need to be a developer to check these signals.

The recurring failures, in plain English

Security researchers and journalists have documented specific patterns in vibe-coded apps. These are not hypothetical. They are what actually goes wrong.

1. The app is publicly reachable when the builder assumed it was private

Some builders set apps to public by default, or the sharing URL provides full access without authentication. In May 2026, security researchers at RedAccess found more than 5,000 vibe-coded apps with little or no authentication or security controls — approximately 40 percent exposed sensitive data, and some allowed admin-level access to anyone with the link.

2. API keys are stored in the wrong place

Your app needs credentials to call paid services: OpenAI, Stripe, Supabase, Twilio, SendGrid. Those credentials must live on the server, not in the browser. When they end up in the browser — embedded in the frontend code or transmitted in a visible network request — anyone who opens developer tools can read them. Lovable's own security guide advises verifying that third-party API keys are server-side and absent from the frontend bundle. Replit's documentation warns that hardcoded secrets can leak through public apps, copy-paste, screen sharing, or streaming. OWASP's Secrets Management guidance recommends limiting access and monitoring secret use.

3. The database is exposed because Row Level Security is not configured

Supabase is the most common database behind vibe-coded apps. It provides a Row Level Security (RLS) system that controls which rows of data each user is allowed to read or change. When RLS is not enabled — or enabled but misconfigured — the database may be accessible to anyone who has the right key, including the anonymous public key that ships in most frontend apps. Supabase's own documentation states that RLS must always be enabled on tables in exposed schemas, and that service-role and secret keys can bypass RLS and must be handled carefully.

4. Login exists, but one user can read another user's records

Having a login screen does not mean data is isolated between users. If the app fetches a record by ID — an invoice, a profile, a message — and does not verify that the logged-in user is the owner of that record, any user can access any other user's data by changing the ID in the URL or in a network request. OWASP identifies Broken Object Level Authorization as one of the most common API vulnerabilities. It is also one of the most common failures in AI-generated API code.

5. Roles are enforced in the browser instead of on the server

If the app shows or hides features based on a role stored in a cookie, a localStorage value, or a JWT claim that the app does not verify server-side, users can manipulate those values and grant themselves admin access or premium features. Community security threads document this pattern repeatedly: users giving themselves premium tiers, cross-user data access, and admin escalation in vibe-coded apps.

6. There are no rate limits or spend limits on expensive operations

AI inference, email sends, SMS, payment retries, and file processing all cost money per call. If anyone — authenticated or not — can trigger those operations an unlimited number of times, a single automated script can run up a large bill before you notice. OWASP API Security (API4:2023) covers unrestricted resource consumption and recommends limits on execution time, memory, records per page, upload size, operations per request, and third-party spending.

7. The code is functionally correct but insecure

This is the hardest one to see from the outside. Veracode tested more than 100 AI models on code generation and found that 45 percent of AI-generated code samples introduced OWASP Top 10 vulnerabilities; JavaScript samples failed security tests 43 percent of the time. The SusVibes benchmark found that the best-performing AI agent/model combination had a 61 percent functional pass rate but only a 10.5 percent secure pass rate. The code does what you asked it to do. It just does not do the security things you did not think to ask for.

Tool-by-tool: what to verify on each platform

Each builder has its own defaults and its own places where things go wrong. These are the specific checks for the most common tools.

Lovable

• Visibility: Check whether your project is set to public or private. Lovable has had at least one documented case where a backend change re-enabled chat access on projects users believed were private. Business Insider covered this in 2026.
• Secrets: Lovable's own security guide advises verifying that third-party API keys are called server-side and are not present in the frontend bundle. Open your browser's network tab while using the app and look for any API keys or secrets in the request headers or response bodies.
• Auth: Confirm that authentication is required before any data is accessible, not just before the UI loads.
• RLS: If your app uses Supabase, confirm that Row Level Security is enabled on every table that contains user data.

Replit

• Secrets: Replit provides a Secrets manager for environment variables. Any credential that is not in the Secrets manager and appears in your code is at risk of leaking through public app URLs, GitHub, or screen sharing. Replit's documentation explicitly warns against hardcoding credentials.
• App visibility: Verify whether your app deployment is public or requires authentication.
• Backend logic: Replit allows real backend code. Confirm that authorization checks — including data isolation between users and role verification — happen in the backend, not in the frontend.

Bolt and v0

• Scope: Both tools generate primarily frontend code. They are well suited for UI prototypes and low-risk internal tools. They are not the right choice for apps that handle user data, payments, or any information that would be damaging if exposed.
• Backend assumption: If Bolt or v0 output connects to a backend service (Supabase, Firebase, a third-party API), all of the backend checks in this guide apply to that service, not to the generated code itself.
• API keys: Review any generated code for hardcoded credentials before deploying anywhere.

Base44

• Auth defaults: Base44 provides visibility controls, role management, and data permission settings in its platform. Wiz found a critical vulnerability in 2026 that could bypass Base44 authentication controls, including SSO, and grant access to private enterprise apps. Base44 (owned by Wix) patched it within 24 hours and reported no evidence of past abuse. The lesson is not that Base44 is unsafe — it is that platform-level auth controls are a dependency you need to understand and verify, not assume.
• Access settings: Review Base44's access management documentation to confirm that your app's visibility, roles, and data permissions are set correctly for your use case.
• Data permissions: Base44 has explicit data permission settings. Review them before inviting users.

Cursor and Claude Code

• More power, more responsibility: These tools give you direct access to the codebase. They are the right choice when you have a repository, a clear set of requirements, and the ability (or a plan) to review what gets generated. They are not plug-and-play safe for non-technical users who have never looked at server-side code.
• Review what was generated: AI-generated code in Cursor or Claude Code should be reviewed by someone who can read the relevant language. The Veracode and SusVibes research cited above was conducted on exactly this class of AI code generation.
• Secrets and environment variables: Confirm that all credentials are in environment variables, not hardcoded in source files. Check your .gitignore before pushing to any repository — a public GitHub repository with API keys in the commit history is a serious exposure.
• Authorization logic: If the app has users, data, or roles, confirm that the authorization logic runs server-side. Trace one request from the browser through to the database query and verify that user identity and permissions are validated at every step.

What to ask an expert to audit

If you are not certain about any of the above — or if your app handles real customer data, payments, or anything sensitive — the questions below are the scope of a practical security review. Bringing this list to a conversation is worth more than a general "can you check this?"

1. Are all API keys and credentials stored server-side and absent from the browser?
2. Is authentication required before any user data is accessible, and is it enforced on the server?
3. Can one logged-in user access another user's records? How is that prevented at the database or API layer?
4. If the app has roles (admin, premium, user), are those roles verified on the server for every request that uses them?
5. Is Row Level Security enabled and correctly configured on every Supabase table that contains user data?
6. Are there rate limits on AI inference, email, SMS, payment, and file-processing endpoints?
7. Are spend limits set on the relevant third-party accounts (OpenAI, Stripe, Twilio)?
8. What happens if an unauthenticated request hits a data endpoint directly?
9. What dependencies does the app rely on, and when were they last updated?
10. What is the incident response plan if a key is exposed or a data breach is discovered?

If you would like AgentC to walk through these questions with your specific app, the right starting point is a demo conversation — not a form. We look at what you have built, ask the questions that matter for your situation, and tell you plainly what is safe to ship and what needs work first.

Related guides in this series

The following articles cover specific topics raised on this page. Each one is a standalone guide for non-technical builders.

• The pre-launch security checklist for Lovable, Replit, Bolt, and Base44
• How to tell if your Supabase database is exposed (without being a developer)
• Production-ready vs demo-good: the vibe-coding reality check
• Which vibe-coding tool should you use? Choose by risk, not hype
• Did the AI put your API keys in the wrong place? How to check and what to rotate
• Can someone see another user's data in your AI-built app?
• You already shipped and now you are worried: a 60-minute containment plan
• What should you ask an expert to audit in your AI-built app?
• Can you add Stripe safely to a vibe-coded app?

Frequently asked questions

Is a vibe-coded app inherently insecure?

No. "AI-built" does not automatically mean insecure. The recurring failures are in specific areas: visibility defaults, secret storage, database access rules, and server-side authorization. Those are configuration and architecture questions, not fundamental limitations of the tools. An AI-built app that has been correctly configured and reviewed is not inherently less safe than any other app. The problem is that AI builders make it fast and easy to skip the configuration work — and most tutorials do not cover it.

What is the most urgent thing to check right now?

Open your browser's developer tools (right-click, Inspect, Network tab) while using your app. If you can see any API keys, Stripe keys, OpenAI keys, or Supabase keys in the network requests — in a request header, a query parameter, a response body — stop and rotate those keys immediately. That is the highest-severity, most time-sensitive issue. Do not ship anything else until that is resolved.

Does adding a login screen make my app safe?

A login screen is a necessary first step, not a complete solution. The most common failure in apps with authentication is that login does not enforce data isolation between users. One logged-in user may be able to access another user's records simply by changing an ID in a URL or a request. OWASP calls this Broken Object Level Authorization, and it is consistently one of the top API vulnerabilities. Authentication answers "who are you?" but authorization answers "what are you allowed to see?" — and most vibe-coded apps configure authentication without checking authorization.

Is my Supabase database exposed?

The most important thing to check is whether Row Level Security is enabled on every table that contains user data. Log in to your Supabase dashboard, navigate to the Table Editor or the Authentication section, and look for RLS settings on each table. If RLS is disabled, the table is accessible to any valid API request — including requests using the anonymous public key that ships in most frontend apps. Supabase's documentation explains how to enable and configure RLS policies. If you are not certain whether your policies are correct, that is worth getting a second opinion on before you invite users.

Can I prompt the AI to write secure code?

Prompting for security improves the AI's intent. It does not verify that the output is actually secure. The SusVibes academic benchmark found a 61 percent functional pass rate versus 10.5 percent secure pass rate for the best-performing AI agents tested on exactly this task. Veracode's testing of more than 100 models found 45 percent of AI-generated samples introduced OWASP Top 10 vulnerabilities. A security prompt is a reasonable starting point. Verification is what makes it real. The verification does not have to be expensive — but it has to happen.

What if I already shipped the app and now I am worried?

Start with the highest-severity items first: take the app private or require authentication if it is currently public, rotate any exposed API keys immediately, and check your Supabase RLS settings. Then work through the rest of the checklist on this page at a deliberate pace. A 60-minute containment plan is covered in detail in You already shipped and now you are worried.

Does AgentC build AI apps, or just review them?

Both. AgentC works with founders and operators who have already built something with AI and need a trusted second opinion — and with people who want to build something right from the start. The right conversation is always a demo or a review, not a form.

Which vibe coding tool is safest for non-technical founders?

There is no single safest tool — they differ in what they provide by default and in where the risks live. Lovable and Base44 provide more built-in auth and access controls than purely frontend tools like Bolt and v0. Replit gives you real backend control, which is safer when used correctly and riskier when the backend logic is not reviewed. Cursor and Claude Code give you the most control and the most responsibility. A full tool comparison by risk level and use case is covered in Which vibe-coding tool should you use?.

About this guide

Written by Seth Tucker, founder of AgentC Consulting. Seth spent approximately five years as a security engineer on election infrastructure used by roughly one in three American voters, holds SOC 2 Type 2 and ISO 27001 experience, and now helps non-technical founders and operators build, review, and trust AI-built applications.

Last updated: June 2026. Sources cited throughout reference original research, vendor documentation, and public reporting.