The three security risks AI builders like Lovable most commonly miss are a privileged API key hardcoded into the client, Supabase Row Level Security not being enabled, and source maps that publish your readable source code. Each is easy to check and fix, and each is the kind of thing an AI code generator produces without flagging, because it builds a working app rather than a secure one. A working app can be wide open: a hardcoded secret can be extracted, a table without Row Level Security is readable by anyone with the public key, and published source maps hand an attacker your original code. Check all three before you treat a Lovable app as production-ready.
Short answer
The risks are hardcoded secrets, missing Row Level Security, and exposed source maps, and all three are checkable. A privileged key in the client can be extracted, so per the OWASP MASVS, secrets must not live in the client. A Supabase table without Row Level Security is open to the public anon key, so per Supabase's Row Level Security docs it must be enabled with policies. Source maps published with your build reconstruct your readable source, so disable or withhold them in production. Check your client for secrets, confirm Row Level Security on every table, and confirm no source map files are served, then fix what fails.
Are API keys hardcoded?
The first thing to check is whether a privileged API key is hardcoded into your client, because AI builders frequently place keys directly in the generated frontend. There is a critical distinction: a public, restricted key such as a Supabase anon key or a Firebase config value is meant to be in the client and is safe, but a privileged secret, an OpenAI or Stripe secret, a Supabase service_role key, or cloud credentials, must never ship, because anyone can extract it from the app and use it to spend your money or read your data.
The risk with AI-generated apps is that the generator wires up whatever key makes the feature work, which is sometimes the privileged one, and it does not warn you. So search your shipped client for any secret beyond the public keys, including the service_role key pattern and any third-party API secret. If you find one, treat it as compromised, rotate it at the provider, and move the operation that needed it behind a backend so your app calls your server and the secret stays server-side. Only public, restricted keys belong in the client.
Is Row Level Security enabled?
The second check is whether Supabase Row Level Security is enabled on your tables, because AI-built apps have shipped with it off, which leaves the database open. Supabase apps query the database directly with the public anon key, so a table without Row Level Security can be read, modified, and deleted by anyone, since the key that makes your app work is available to everyone. This was the root of the widely-reported vulnerability in AI-generated apps, where hundreds of databases were fully accessible.
An app with Row Level Security disabled works normally while being wide open, so functioning correctly is not evidence that it is secure. Check the Row Level Security status of every table in your exposed schema in the Supabase dashboard, and confirm each has Row Level Security enabled with policies that tie access to the authenticated user rather than allowing everyone. Also watch for a policy that is technically enabled but grants access unconditionally, which is open despite appearing protected. Enabling Row Level Security with user-scoped policies is what makes the public anon key safe.
Are source maps exposing your source?
The third risk, and the one most often overlooked, is published source maps. When a web app is built, source maps are files that map the minified production code back to your original readable source, and if they are deployed and served alongside your app, anyone can open the developer tools and read your source code as you wrote it, including component logic, comments, and any secret or endpoint you embedded. For an AI-built app deployed with default build settings, these files may be published without you realizing it.
The exposure is twofold: source maps make it trivial to read what your app contains, which amplifies every other risk, and they can directly reveal secrets or internal structure you assumed were obscured by minification. Check whether your deployed app serves source map files, typically files ending in a map extension referenced by your scripts, and if it does, disable source map generation for your production build or ensure the map files are not published. Removing them does not fix a hardcoded secret, but it stops handing attackers a readable copy of your code.
Why AI builders miss these
AI builders miss these risks because their goal is a working app, and none of the three prevents the app from working. A hardcoded secret makes the feature function, a table without Row Level Security serves data correctly to your own app, and published source maps do not affect behavior at all, so from the generator's perspective everything is fine. The security problems are invisible at the level of does the app run, which is what the AI optimizes for.
There is also a knowledge gap: the generated code reflects common patterns from its training, which include insecure ones, and it does not carry the judgment to say that this particular key should not be in the client or that this table needs Row Level Security. The result is that vibe-coded apps reach production with security gaps their builders never saw, not through malice but because the tool does not surface them. This is why an explicit security check is necessary before shipping, rather than assuming the generator handled it.
How to check your Lovable app
Checking your app is a direct process for each risk. For hardcoded secrets, inspect your shipped client code and bundle for any key beyond the public ones, searching for the service_role pattern and known secret prefixes, and check your repository history too. For Row Level Security, open your Supabase dashboard and review every table's Row Level Security status and policies, then test with your anon key by attempting to read data that should be private and confirming it is blocked.
For source maps, load your deployed app, open the browser developer tools, and look at the sources, checking whether your original files and readable source appear or whether map files are being fetched. If you can read your uncompiled source in the browser, source maps are exposed. Run all three checks rather than one, because they are independent, and an app can pass one while failing another. Together they tell you whether your Lovable app is safe to ship or needs the fixes below first.
Fixing the three risks
Fixing follows directly from the checks. For a hardcoded secret, rotate the exposed key, remove it from the client, and route the operation through a backend so the secret lives on your server, keeping only public keys in the app. For missing Row Level Security, enable it on every exposed table and write policies that scope access to the signed-in user with the standard user-identifier comparison, then verify with the anon key that private data is blocked.
For source maps, turn off source map generation in your production build configuration, or configure your deployment so the map files are not served, so your readable source is no longer public. Make these part of a pre-launch review rather than a one-time fix, since regenerating the app or adding features can reintroduce them. None of the fixes is time-consuming, and together they close the three gaps AI builders most often leave, turning a working-but-open app into one that is both working and secure.
The three risks at a glance
Seeing the three together focuses your review. The table below compares them.
| Risk | What the AI builder misses | Fix |
|---|---|---|
| Hardcoded API secret | A privileged key placed in the client | Rotate, use a backend proxy, ship only public keys |
| Row Level Security off | A Supabase table open to the anon key | Enable Row Level Security with user-scoped policies |
| Published source maps | Readable source served to anyone | Disable or withhold source map files |
Read the table as a three-point audit: each risk is independent, so check all three, since passing one says nothing about the others.
Security checklist
Working through these steps secures a Lovable app before launch. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Check for secrets | No service_role key or API secret in the client | [ ] |
| Check Row Level Security | Enabled with policies on every exposed table | [ ] |
| Check source maps | No readable source or map files served | [ ] |
| Add a backend proxy | Privileged calls run server-side | [ ] |
| Rotate exposed keys | Roll any secret that shipped | [ ] |
| Re-scan before launch | Confirm the build is clean | [ ] |
The step that catches the most damaging issue is checking for a secret in the client, because a leaked privileged key is exploitable immediately, unlike source maps which mainly expose code.
Scan your build
Because the most damaging of these risks is a hardcoded secret, and it is easy to miss in AI-generated code, scanning what actually ships is the reliable way to know. The gap between what the generator produced and what is safe to publish is exactly what a security scan surfaces.
A scanner like PTKD.com analyzes your build and reports issues such as leaked keys and secrets, insecure data storage, and over-broad permissions by severity, mapped to OWASP MASVS, so a privileged key the AI builder placed in the client is flagged before release. To be clear about the boundary: PTKD does not enable your Supabase Row Level Security or configure your source map settings, which you handle in Supabase and your build config. It finds the secrets in the shipped app so you know what to rotate and remove, the highest-impact of the three checks.
What to take away
- The three risks AI builders like Lovable most commonly miss are a hardcoded privileged key, Supabase Row Level Security not enabled, and published source maps.
- A public key such as a Supabase anon or Firebase config value is safe in the client, but a service_role key or third-party secret must never ship and belongs behind a backend.
- A Supabase table without Row Level Security is open to the anon key, so enable it with user-scoped policies, since a working app can still be wide open.
- Published source maps let anyone read your original source, amplifying every other risk, so disable or withhold them in production.
- Check all three independently, fix what fails, and scan the shipped build with a tool like PTKD.com to catch a hardcoded secret.
