Lovable App Security Review: Bolt, Replit, v0 (2026)

A Lovable app security review (or the same review for a Bolt, Replit Agent or v0 app) checks the parts the builder generated but nobody reviewed: database access rules, keys shipped to the browser, server endpoints that skip authorization, webhooks, and any AI features. The single most important test is simple to describe: log in as two different users on the running app and prove that neither can read or change the other’s data through the UI, the API or the database directly.

This post is the practical companion to our Lovable data leak analysis. That piece covered why the problem exists. This one covers what to test, platform by platform, and how to scope it.

How common are these flaws in vibe-coded apps?

Common enough that you should assume your app has at least one until a test says otherwise.

Escape notes that most issues were reachable without authentication. That matters: nobody needed to be a clever attacker. They needed a browser and the network tab.

What should a Lovable app security review check?

Lovable generates a React front end and, for anything with data or logins, a Supabase backend. So Lovable app security is really Supabase security plus a few Lovable-specific habits.

• Row level security on every table. Supabase exposes your Postgres tables through an auto-generated REST API. Supabase’s own docs say RLS must be enabled on any table in an exposed schema. We check every table, view and function, not just the ones the UI uses.
• Policies that actually restrict. RLS switched on with a policy like using (true) is the same as no RLS. A real Supabase row level security audit reads each policy and then tries to break it: reading other users’ rows, inserting rows with someone else’s user_id, updating a row you can read but should not edit.
• Anon key versus service key. The anon (now “publishable”) key is designed to be public. The service_role (or “secret”) key bypasses RLS entirely. We search the built bundle, the repo and its git history for anything that is not meant to be there. See Supabase on API keys.
• Edge functions. Lovable often moves payment calls, email sending and AI calls into Supabase edge functions. Each one is a public URL. We check that it verifies the caller’s JWT, checks ownership, and does not use the service key to do something the caller is not allowed to do.
• Storage buckets. Public buckets for avatars are fine. Public buckets for invoices, ID scans or contracts are not.
• Roles stored where users can edit them. An is_admin column on a profile table that users can update is a classic generated-app flaw.

Lovable now runs a security scan before publish, built on Supabase’s Security Advisor, plus an AI security review for things like hardcoded secrets and unprotected edge functions (Lovable on secure vibe coding). Run it. It catches missing RLS well. It cannot tell you whether a policy matches your business rules, and it does not exercise a running app with real sessions.

What does Bolt app security involve?

Bolt.new runs the app inside StackBlitz WebContainers, an in-browser Node.js runtime. That is a development environment, not your production attack surface. What ships is a normal web app hosted on Bolt Cloud or a host such as Netlify, and the backend is where problems live.

• Which database you have. According to Bolt’s support docs, projects created after 30 September 2025 use Bolt Database by default, while older projects and anyone who opted in use their own Supabase project. If it is Supabase, the whole Lovable checklist above applies. Either way, we test access rules against the running app.
• Firebase backends. Some Bolt projects use Firebase instead. The equivalent of RLS there is Firestore and Storage security rules, and the classic flaw is the same: rules left open after testing.
• Environment variables. Anything prefixed VITE_ or NEXT_PUBLIC_ is compiled into the browser bundle. That is fine for a Supabase anon key and a disaster for a Stripe secret key or an OpenAI key. Bolt’s Secrets section is meant for server-side values used in server functions; we confirm nothing sensitive went the other way.
• Committed .env files. If you exported to GitHub, we check the repo and its history, because a deleted secret is still in old commits.

Bolt app security reviews also look at the gap between preview and production: features that worked in the preview with permissive settings, then shipped with those settings unchanged.

What are the main Replit app security risks?

Replit Agent builds full-stack apps on Replit’s own infrastructure, typically with a Postgres database, and deploys them from the same workspace. Replit app security has a different flavour because the agent has hands, not just a keyboard.

• Secrets handling. Replit’s Secrets tool encrypts values and exposes them as environment variables, at app or account level. We check that keys actually live there, not in source files, logs or API responses, and that account-level secrets are not shared more widely than needed.
• Agent-run destructive actions. In July 2025, Replit’s agent deleted a production database during a user’s declared code freeze (The Register). Replit responded by separating development and production databases (Replit docs). We check that your app uses that split, that the agent cannot touch production data, and that you have restored a backup at least once.
• Deployments. A deployed Replit app is a public web server. Typical findings are the same as any hand-built Express or Flask app: missing authorization on API routes, IDOR on numeric IDs, debug endpoints left on, and verbose errors that leak stack traces or connection strings.
• Auth. Whether the app uses Replit Auth or its own login, we test session handling, password reset and account takeover paths.

What should a v0 security review cover?

v0 generates Next.js apps that usually deploy to Vercel. The front end looks polished; the risk sits in code that runs on the server but is callable from anywhere.

• Server actions. The Next.js docs say to treat server actions like public HTTP endpoints. A form that only appears on a protected page does not protect the action behind it. Every action needs its own session check and an ownership check on the record it changes.
• API routes. Same rule for route handlers. We call each one directly, with no session, a different user’s session and malformed input.
• Middleware-only auth. CVE-2025-29927 let attackers bypass authorization implemented only in Next.js middleware on affected self-hosted versions. Auth should be enforced again close to the data.
• NEXT_PUBLIC_ variables and server components. We check for secrets in the client bundle and for server components that pass whole database rows (including fields like password_hash or stripe_customer_id) down to the browser.

What does a proper AI app builder security test include?

Platform aside, AI app builder security testing comes down to the same list. This is what we run against a deployed instance:

1. Authorization and IDOR. Two or more test accounts per role. Every object ID in every request swapped between accounts, through the UI and by calling the API directly.
2. RLS and database rules. Direct calls to the Supabase REST endpoint or the equivalent, using only the public key and a normal user token.
3. Secrets. The production JavaScript bundle, source maps, the repo and the full git history, plus API responses that echo config.
4. API overexposure. Endpoints that return more fields than the UI shows, list endpoints with no pagination limit, and admin routes reachable by normal users.
5. Webhooks. Stripe, payment gateway or form webhooks that do not verify signatures, so anyone can post a fake “payment succeeded” event.
6. LLM features. If the app has a chat, summariser or agent: prompt injection through user content, system prompt and tool leakage, and AI provider keys exposed in the client. This is where our AI security assessment or LLM penetration test comes in.
7. Rate limiting and spend caps. Login, signup, password reset and any endpoint that calls a paid API. An unprotected AI endpoint is a bill waiting to happen, so we also check that provider-side spend limits are set.
8. Business logic. Coupon reuse, plan limits enforced only in the UI, invite flows that let you join any workspace.

Static review or pentest on a running app?

Both have a place. They answer different questions.

If you are pre-launch and want a fixed list of what to fix in the code, the lighter first step is the Ship-Ready Audit on nomadx.ae, a fixed-scope code-level review. When you need proof that the running app holds up, that is a web application penetration test.

What does UAE law expect if your app handles personal data?

If you process personal data of people in the UAE, the Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) applies, regardless of which tool wrote the code. It requires appropriate technical and organisational measures to protect personal data and notification to the UAE Data Office when a breach affects people’s privacy. “Lovable generated it” is not a defence. Companies in DIFC and ADGM fall under their own data protection laws instead, with similar security duties.

For payments, the Central Bank of the UAE regulates licensed payment service providers. Most startups take payments through a licensed provider such as a payment gateway and never hold card data themselves, so CBUAE rules apply to the provider, not you. If you are applying for a licence or selling to a licensed bank or PSP, expect their vendor due diligence to ask for a recent penetration test. Our guide to web application penetration testing in the UAE covers sector rules in more detail.

How big should the review be?

Scope follows data sensitivity and who is asking for the report, not the platform.

Ask us for a scope and we reply with the test plan and dates. We do not publish prices; the quote depends on roles, endpoints and AI features.

How do you prepare for the review?

A little prep saves a day of testing time.

• Two test accounts per role on a staging or production-like environment, with realistic sample data.
• A list of roles and what each may see. “Team members see their team’s projects, admins see billing.” This is what we test authorization against.
• Repo access, including the full history, if you want secrets and code-level findings.
• Backend details: Supabase project, Bolt Database, Replit Postgres or Vercel project, plus which third-party services you call.
• Run the built-in scanner first (Lovable’s security scan, Supabase Security Advisor) and fix what it finds, so the test spends its time on the hard problems.
• Rotate anything you already suspect leaked before the test, not after.

Get your vibe-coded app tested before it ships

pentest.ae tests apps built on Lovable, Bolt.new, Replit Agent and v0 with the same manual depth as any production web app: two-account authorization testing, a Supabase row level security audit, secrets in bundle and history, webhooks and AI features, with a retest of fixes included. If you are earlier than that, start with the Ship-Ready Audit and come back for the pentest when real data arrives.

Prefer to talk first? Contact us for a free scoping call.