The pre-launch security checklist for Lovable, Replit, Bolt, and Base44
By Seth Tucker · Updated June 2026
Before you send the link, run this checklist.
These are the specific things to verify before a vibe-coded app touches real users or real data. The checklist is organized in two parts: a universal set of checks that applies to any AI-built app regardless of tool, and a short per-platform section covering where each builder most commonly diverges. Most items take five minutes to verify. One or two require a developer's help. The rest are in your control right now.
Download the AgentC Vibe-Coded App Audit Checklist
The full interactive version of this checklist — with a status column you can fill in, a risk score, and a "what to do if this fails" note for each item — is available as a free, open-access page.
Open the AgentC Vibe-Coded App Audit Checklist — no form required.
The universal checklist
These apply regardless of whether you built in Lovable, Replit, Bolt, v0, Base44, Cursor, or Claude Code.
Section 1: Who can reach your app
| Check | How to verify | If it fails |
|---|---|---|
| The app requires a login before any content or data is visible | Try opening your app URL in a private/incognito browser window without logging in | Enable authentication in your builder's settings before inviting anyone |
| If the app is intentionally public (no login), it contains no user data, no payments, and nothing sensitive | Review what the app shows to an unauthenticated visitor | Restrict access or remove the sensitive capability until auth is in place |
| Visibility settings are confirmed, not assumed | Check your builder's sharing or deployment settings; do not rely on what you remember setting | Review the per-tool section below for where each builder's setting lives |
| You know who has the link or access | Review any shared URLs, team invitations, or published deployment links | Revoke and reissue access with explicit control over who holds each link |
Section 2: Secrets and API keys
| Check | How to verify | If it fails |
|---|---|---|
| No API keys appear in the browser | Open your app, right-click, select Inspect, go to the Network tab, reload the page, and look for any API keys, tokens, or credentials in request headers, query parameters, URL strings, or response bodies | Rotate the exposed key immediately at its source (OpenAI dashboard, Stripe dashboard, Supabase dashboard, etc.), then move the key server-side before continuing |
| No secrets are hardcoded in the frontend code | Review any generated frontend code files for strings that look like tokens, passwords, or credentials | Move them to your builder's secrets or environment variable system and redeploy |
| Third-party service keys (OpenAI, Stripe, Twilio, SendGrid, Supabase service-role key) are stored server-side | Check your builder's secrets/environment variable configuration and confirm the key names match what the backend code references | Use your builder's secrets manager (Replit Secrets, Lovable's environment settings, etc.) |
| Credentials are not exposed in version control | If your project is connected to GitHub, check that .gitignore excludes .env and any config files with secrets | Rotate the key, remove from commit history, and update .gitignore |
Lovable's own security guide advises verifying that third-party API keys are called server-side and are not present in the frontend bundle. Replit's documentation warns that hardcoded secrets can leak through public app URLs, GitHub, copy-paste, or screen sharing. OWASP's Secrets Management guidance recommends limiting access and actively monitoring secret use.
Section 3: Authentication and data isolation
| Check | How to verify | If it fails |
|---|---|---|
| Authentication is required before the server returns any user data — not just before the UI loads | Try accessing a data endpoint directly (copy a network request URL from the Network tab and open it in a new browser tab, logged out) | Server-side authentication middleware is missing; this requires a developer fix |
| One logged-in user cannot access another user's records by changing a URL or request parameter | Log in as User A, note the URL of a record (invoice, profile, message, order), log out, log in as User B, and navigate to the same URL | This is Broken Object Level Authorization — OWASP identifies it as one of the most common API vulnerabilities; it requires a server-side fix |
| If the app has roles (admin, premium, user), role checks happen on the server | Inspect the JWT or session cookie your app uses; check whether the backend verifies the role on each request | Frontend-only role checks can be manipulated; this requires a server-side fix |
| Password reset, email verification, and account deletion work correctly and only affect the correct account | Test each flow manually using a test account | Broken account management flows can expose user data or allow account takeover |
Section 4: Database access
| Check | How to verify | If it fails |
|---|---|---|
| If using Supabase: Row Level Security (RLS) is enabled on every table that contains user data | Log in to your Supabase dashboard, go to Table Editor, click each table, and look for the RLS indicator | Enable RLS immediately; without it, any request with a valid key can read the entire table |
| If using Supabase: the anon (public) key cannot be used to read or modify other users' data | Test using the Supabase API directly with the anon key and a query for another user's records | RLS policies need to be written or corrected |
| If using Firebase, PocketBase, or another BaaS: access rules are configured on the backend | Review your service's security rules documentation and check what the default allows | "Allow all" or blank rules are common defaults that expose all data |
| The service-role or admin key is not in the frontend | Check that only the anon/public key is referenced in your frontend code; the service-role key should only appear in server-side logic | Rotate the service-role key immediately; treat it as compromised |
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.
Section 5: Rate limits and spend controls
| Check | How to verify | If it fails |
|---|---|---|
| Spend limits are set on your OpenAI, Anthropic, and any other AI inference accounts | Log in to each AI provider's dashboard and confirm a monthly spend limit is set | Set a spend limit now; a single automated script can exhaust credits in minutes |
| Spend limits are set on Stripe, Twilio, SendGrid, or any other paid-per-call service | Check each service's dashboard for billing alerts or monthly limits | Enable alerts and limits; an exposed endpoint without limits is an open billing risk |
| AI, email, SMS, or payment endpoints have rate limits — per user and per IP | Check whether your app limits how many times a single user or IP can trigger expensive operations in a given time period | Rate limiting requires code or infrastructure changes; add it before inviting users who are not personally known to you |
| File upload endpoints have file size and type restrictions | Try uploading a very large file or an unexpected file type | Unrestricted uploads can be used for storage abuse or to trigger processing costs |
OWASP API Security (API4:2023) covers unrestricted resource consumption and recommends limits on execution time, memory, records returned per page, upload size, operations per request, and third-party spending.
Per-tool specifics
Lovable
- Visibility: Confirm your project's visibility setting explicitly. Business Insider reported in 2026 that a backend change re-enabled chat access on projects users believed were private; Lovable reverted the change, but the incident illustrates that visibility defaults can shift.
- Secrets: Lovable's own security guide advises verifying that third-party API keys are called server-side and absent from the frontend bundle. Open the Network tab while using the app and inspect requests for credentials.
- Auth and RLS: If your app uses Supabase (the most common backend for Lovable apps), confirm RLS is enabled on every table and that the anon key in your frontend cannot query another user's rows. See How to tell if your Supabase database is exposed for a full Supabase walkthrough.
- Generated code: Lovable generates real backend code. If you have a developer available, have them review the authentication middleware and database query logic before you invite users.
Replit
- Secrets manager: Use the Replit Secrets tab for every credential. Any key that is not in the Secrets manager and appears in the code is at risk of leaking through public app URLs, GitHub, copy-paste, or screen sharing.
- Deployment visibility: Confirm whether your Replit deployment is public or requires authentication at the deployment level, not just in the app logic.
- Backend control: Replit allows real server-side code. If your app has users and data, confirm that authentication and data isolation checks happen in the backend — not in frontend JavaScript.
- Rate limits: Replit does not automatically rate-limit your endpoints. If your app has AI or payment features, you need to add rate limiting in your server code.
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 appropriate for apps that will handle user data, payments, or any information whose exposure would cause harm or embarrassment.
- Backend dependencies: If Bolt or v0 output connects to a backend service (Supabase, Firebase, a third-party API), all of the checks in this guide apply to that backend service — not to the generated frontend code itself.
- Hardcoded credentials: Review any generated code for API keys or secrets before deploying. Even a brief deployment of frontend code containing credentials is enough for automated scanners to harvest them.
- Path to production: If you are planning to add real users or payments to a Bolt or v0 app, the architecture likely needs to grow beyond what these tools generate. Plan for that transition before you invite users.
Base44
- Access settings: Base44 provides visibility controls, role management, and data permission settings in its platform. Review the access documentation and security settings explicitly for your app's configuration.
- Roles and data permissions: Base44 has explicit data permission settings. Verify which users can read or write each data type before inviting users you do not personally know.
- Platform dependency: Wiz found a critical authentication bypass vulnerability in Base44 in 2026 that could grant access to private enterprise apps, including SSO bypass. Wix/Base44 fixed it in less than 24 hours and reported no evidence of past abuse. The lesson is not that Base44 is unsafe — it is that any platform-level authentication control is a dependency that can have vulnerabilities, and platform updates matter.
- Keep the platform updated: If Base44 releases a security update, apply it. Do not run a stale version of a platform-managed app for months after security fixes are released.
Cursor and Claude Code
- Environment variables: Confirm that all credentials are in environment variables, not hardcoded in source files. Check your
.gitignorebefore pushing to any repository. A public GitHub repository with API keys in the commit history is a serious exposure that requires key rotation and history rewriting. - Review what was generated: AI-generated code in Cursor or Claude Code should be reviewed by someone who can read the relevant language and framework. Veracode's testing of more than 100 AI models found that 45 percent of AI-generated code samples introduced OWASP Top 10 vulnerabilities; JavaScript samples failed security tests 43 percent of the time.
- Authorization trace: If the app has users, data, or roles, trace one request from the browser all the way to the database query. Confirm that user identity and permissions are validated at every step — in the API handler, not just in the frontend.
- Dependency audit: Run a dependency audit before launch. AI-generated code frequently imports packages; old or unmaintained packages can carry known vulnerabilities.
What this checklist does not cover
This checklist covers the most common failure modes in vibe-coded apps before first user launch. It does not cover:
- Health, financial, legal, or regulated data, which carry compliance requirements beyond this scope — get expert review before handling any of these categories.
- Long-term operational security: logging, monitoring, alerting, incident response, and backup verification.
- Advanced authorization patterns: multi-tenancy, attribute-based access control, or complex role hierarchies.
- Code-level static analysis, dependency auditing at depth, or penetration testing.
If you are not certain about any item on this checklist — or if your app touches payments, private customer data, or anything regulated — the questions in the checklist are the starting point for a practical review conversation.
What to ask an expert
Bring this checklist to a review conversation and highlight any item you could not verify. The highest-priority items to flag are:
- Any API key visible in the browser's Network tab.
- Any table in Supabase with RLS disabled.
- Any user data endpoint you were unable to test for object-level isolation.
- Any AI, email, SMS, or payment feature without rate limits.
If you want AgentC to walk through this checklist with your specific app, the right starting point is a demo conversation. We review what you have built, work through the items that are unclear, and tell you plainly what is safe and what needs work before you share the link.
Related guides in this series
- Is your AI-built app safe to put in front of customers? (the pillar guide) — start here if you are new to this topic
- How to tell if your Supabase database is exposed (without being a developer)
- Production-ready vs demo-good: the vibe-coding reality check
- Did the AI put your API keys in the wrong place? How to check and what to rotate
- You already shipped and now you are worried: a 60-minute containment plan
Frequently asked questions
Do I need to complete this entire checklist before sharing my app with anyone?
The most critical sections are 1 (visibility), 2 (secrets), and 4 (database access). If you cannot complete those three sections with passing results, do not share the app with anyone who is not directly involved in building it. Sections 3 and 5 matter as soon as real users or real transactions are involved. The full checklist applies before a paid or public launch.
I built my app with Lovable / Replit / Base44. Does that mean authentication is handled for me?
Platform-provided authentication covers the login flow. It does not automatically enforce data isolation between users (object-level authorization), server-side role checks, or correct database access rules. Those require explicit configuration — and they are where most of the real failures happen.
How do I know if an API key is "in the browser"?
Open your app in a browser, right-click anywhere on the page, and select Inspect (or press F12). Go to the Network tab. Reload the page and use the app — add something to a cart, trigger an AI response, submit a form. Look through the network requests that appear for anything that looks like a long string of random characters in a header, URL, or response. Search for "key," "token," "secret," "sk-," "pk_," or "anon." If you find one that is not the Supabase anon key embedded in the frontend (which is intended but must be paired with RLS), rotate it immediately.
Does this checklist apply if I only shared the link with a few trusted people?
Yes, for sections 2 and 4. An exposed API key or an RLS-disabled database table is not a problem you can scope by limiting who has the link — those are server-side exposures that are accessible to anyone who can find the endpoint, whether or not they have the sharing link. Sections 1, 3, and 5 can be addressed more gradually if access is genuinely restricted to known individuals.
Is there a single most important item?
Open the browser Network tab and look for API keys in requests. That is the highest-severity, most time-sensitive check — an exposed key can be harvested by automated scanners in hours and used to run up costs or exfiltrate data. Everything else can be addressed in sequence after that.
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.
More than vibes
Want a second set of eyes on your app?
The right starting point is a demo conversation, not a form. We look at what you built, ask the questions that matter for your situation, and tell you plainly what is safe to ship and what needs work first.