Skip to content

Is Your App Built with Lovable Secure? 7 Checks to Run Before Launch

Seven security checks, in order of urgency, to run before you open your app to real users.

Author

G. Tempesta

Published

Reading

4 min

Updated

Written with AI assistance, reviewed by Giovanni Tempesta

Is Your App Built with Lovable Secure? 7 Checks to Run Before Launch

Tools such as Lovable, Cursor and Bolt are great for getting started: in a few days you go from an idea to an app that really works. The problem comes later. AI writes code that works in the ideal case, but it does not always add the checks you need when real users arrive. And security is the part you see least: the app works perfectly, until someone opens the browser's developer tools.

In the code of the AI-built apps I read, security problems are the most frequent. Here are the seven checks I would run before launching, in order of urgency. You can do some of them yourself; for others you need a developer.

1. No secret keys in the browser

Everything in the frontend code reaches the browser of whoever visits the site. That includes environment variables prefixed with VITE_ or NEXT_PUBLIC_: they end up in the downloaded JavaScript, readable by anyone.

If your OpenAI key is in there, anyone can use it at your expense.

How to check: open the site, press F12, go to the sources tab and search for sk- or the name of the service. How to fix it: calls that use secret keys move to a server-side function (for example a Supabase Edge Function), where the key never leaves the server.

2. The Supabase service key is neither in the frontend nor in the repository

Supabase has two keys. The public one (anon) is meant to live in the browser. The service key (service_role), on the other hand, bypasses all access rules: whoever has it can read, change and delete everything.

How to check: search for service_role in the frontend code and in the repository, including the commit history. If you find it: regenerate it from the Supabase dashboard, update the server functions that use it and remove it from the code. Deleting it from the file is not enough: it stays in the history.

3. Every table has its own access rules

Since the public key really is public, the only thing protecting your data is the database's access rules (Row Level Security). A table without rules can be read and changed by anyone who has that key, which means anyone who visits the site.

How to check: in the Supabase dashboard, look at which tables have rules switched off; the Security Advisor flags them too. Then check that the rules are not simply “true for everyone”.

4. Uploaded files are not public unless they need to be

Documents, CVs, invoices: if they sit in a public bucket, anyone with the link can download them, even without signing up.

How to check: look at the settings of your storage buckets. Private documents need a private bucket and temporary links generated by the server.

5. The admin panel is protected, not just hidden

Hiding a button or a page in the frontend is not protection. If admin operations are allowed by the database or the server for any registered user, it is enough to call them directly.

How to check: log in as a normal user and try to open the admin page's address, or to repeat one of its operations. The check must live in the database rules or on the server.

6. The paid plan cannot be unlocked from the browser

If the information “this user has paid” sits in a column the user can change, or if the check happens only in the frontend, the Pro plan can be unlocked without paying.

How to fix it: the payment status is written only by the server, for example when the Stripe confirmation arrives, and the user cannot change it.

7. No debug mode in production

Detailed error messages are useful while you develop. In production they tell anyone how your server is built: paths, table names, sometimes parts of queries.

How to check: trigger an error (for example an address that does not exist or a badly filled-in form) and see what appears.

If even one of these points leaves you in doubt

It is not just you: these are the problems I find most often. None of them makes your app a bad product. It simply means that before opening it to real users, someone needs to reread the code with eyes other than those of the AI that wrote it.

Would you like me to check it? With the AI Code Check-up I read your app's code and tell you what is broken, what is risky and how much it costs to fix. Fixed price, NDA before access. Find out about the AI Code Check-up

  • Vibe Coding
  • Lovable
  • Supabase
  • Sicurezza