If you are about to share your Lovable preview link, or worried one is already floating around, the honest answer is that a preview URL is public to anyone who has it. The link is random, but it is not a private sandbox. It serves your real app, so it is exactly as secure as the app behind it. Here is what that does and does not expose.
Short answer
A Lovable preview URL is public by default: the link is random but reachable by anyone who has it, with no authentication unless you add it. Because it serves your real client code, an exposed API key or a Supabase table with Row Level Security disabled is reachable through the preview just as it would be in production. Your project editor and source code are private to your workspace by default, per Lovable's project access settings, but the deployed app at the preview URL is not. The fix is to secure the app itself before you share the link.
What you should know
- The preview link is public: random, but anyone who has it can open the running app.
- It runs your real app: client-side keys and database access behave the same as production.
- Source code is separate and private: your editor and project are workspace-only by default, not exposed by the app URL.
- Obscurity is not security: a hard-to-guess URL does not protect data; authentication and access rules do.
- A 2026 incident proved the stakes: exposed keys and RLS-off tables led to real data exposure on Lovable projects.
Is the Lovable preview URL public?
Yes. The preview URL is generated with a random path, but it is publicly accessible, so anyone who receives or finds the link can open your app. There is no built-in password or login on the preview itself unless you add authentication inside the app. Lovable users have asked for an option to lock preview URLs to specific people, which underlines the default: the link is the only barrier, and a link is easy to forward. Treat the preview the way you would treat a live site, because functionally it is one.
What does the preview URL actually expose?
Whatever your client app exposes. The preview serves the same JavaScript bundle and makes the same network calls as your published app, so anything readable there is readable through the preview. That includes an API key hardcoded in the frontend and any Supabase table left reachable by the public anon key. This is not hypothetical: in a 2026 Lovable security incident, reported by Lovable, keys for services like OpenAI and Stripe sat in JavaScript files viewable in browser developer tools, and tables with Row Level Security disabled were queryable by anyone holding the public anon key. The preview URL did not create those weaknesses; it made them reachable. The useful way to think about it is that the preview is a fast way for anyone to reach whatever your client already gives away, so the question is not whether the URL is safe, but whether the app behind it would survive a stranger opening developer tools.
Is the preview URL the same as my project visibility?
No, and the distinction matters. Two different things have access settings. The deployed app, at the preview or published URL, is public by default so people can use it. Your project, meaning the editor, the chat history, and the source code, is private to your workspace by default as of late 2025, and after the April 2026 incident Lovable removed public project visibility entirely and moved existing public projects to workspace access. So someone with your preview link can use the app, but they do not get your source or your editor through that link. The two questions, who can use the app and who can see the project, have separate answers. Knowing which one a worry belongs to saves time: if you are anxious about strangers using an unfinished app, that is the public app URL and authentication is the answer, while if you are anxious about someone reading your prompts or code, that is project visibility, which is already workspace-only by default.
How do you secure it before sharing?
Lock down the app, not just the link. The steps that matter:
| Control | What it does |
|---|---|
| Authentication | Requires users to sign in, so the app is not open to anyone with the link |
| Supabase Row Level Security | Stops the public anon key from reading or writing data it should not |
| Secrets server-side | Keeps API keys off the client, where the preview would otherwise expose them |
| Lovable's built-in scanners | Flag exposed keys and RLS gaps, though they cannot guarantee complete security |
| Limited sharing | Share the link only with people who need it while the app is unfinished |
Run Lovable's security checks, enable Supabase Row Level Security on every table, and move provider calls behind server-side functions before the link goes anywhere.
What to watch out for
The core trap is treating the random URL as protection. Security through obscurity fails the moment the link is shared, indexed, or guessed, and Lovable's own scanners are explicit that they help find issues but cannot guarantee complete security. For a related view on how AI-built apps get attacked, see can Rork apps be hacked. If you wrap a Lovable web app into a mobile app for the App Store, the same client-side keys ship inside the binary, so a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA for hardcoded secrets against OWASP MASVS. The preview link and the mobile binary are two windows onto the same client code, so close both.
What to take away
- A Lovable preview URL is public to anyone with the link, with no authentication unless you build it in.
- It serves your real client app, so exposed keys and RLS-off tables are reachable through it, as a 2026 Lovable incident showed.
- Your editor and source are private to your workspace by default, which is separate from the public app URL.
- Secure the app with authentication, Supabase Row Level Security, and server-side secrets before sharing, and scan the binary with a pre-submission scan such as PTKD.com if you ship a mobile build.
