Is your Lovable, Bolt or v0 app secure? 10 things to check

Why AI-built apps tend to share the same weak spots

Tools like Lovable, Bolt, v0, Replit, Cursor and Claude are good at what you can see: screens, buttons, forms and a database behind them. Security is something you cannot see. An app in which every user can request the data of every other user looks exactly the same as one in which they cannot. As long as nobody tries, you will not notice the difference.

On top of that, an AI tool builds what you ask for. Ask for a customer overview and you get a customer overview. Whether that overview is only visible to the right people depends on rules you have to ask for yourself, and which the AI sometimes removes again when something does not work straight away.

2025 showed this is not just theory. A vulnerability was registered for apps made with Lovable (CVE-2025-48757): because the database rules were too loose, outsiders could read or change data without logging in. Lovable disputes the registration, arguing that each customer is responsible for protecting the data in their own app. And that is exactly the point: the responsibility is yours, even when an AI wrote the code.

The good news is that the mistakes look alike. If you know where to look, you will find most of them within a few hours. Below are the ten points I check first in every app.

The 10 things to check

Work through the list from top to bottom. The first three points matter most: that is where the leaks are that let someone take all of your data in one go.

1. 1Secret keys: are keys for, say, Stripe, OpenAI or the Supabase service_role key in code that runs in the browser? Then anyone can find and use them.
2. 2Database rules: is Row Level Security switched on in Supabase for every table, or are your Firebase Security Rules stricter than ‘anyone can do anything’? Without those rules, your database is open from the browser.
3. 3Per-user permissions: does a logged-in user only see their own data? Test it with two accounts, and see what happens when you change the number of a customer or order in the address bar.
4. 4Admin pages: have admin pages only been removed from the menu, or does the server really check whether someone is an admin?
5. 5Input: does your app check what users enter, on the server side as well? Unchecked input opens the door to injection, where someone gets their own code or database commands executed.
6. 6Packages and updates: does your app run on packages with known vulnerabilities (CVEs)? The older the packages, the bigger the chance.
7. 7Files and storage: who can view uploaded files? A storage folder set to public can be read by anyone who has or guesses the link.
8. 8Abuse: can someone try to log in a thousand times a minute, or run your AI feature on your bill? Without limits, you pay for the abuse.
9. 9Error messages: does your app show technical details when something fails, such as database names or pieces of code? That information helps an attacker along.
10. 10Backups, logs and monitoring: can you restore your data when things go wrong, and will you notice an outage or a break-in before your customers tell you?

Keys and database rules: start here

An app that runs on Supabase uses two kinds of keys. The public key (the anon key, or the publishable key in newer projects) belongs in the browser and may be seen. The secret key (service_role, or secret key) bypasses every database rule and belongs on a server only. According to the Supabase documentation, that key must never end up in the browser, or anywhere else users can see it.

That public key is only safe if the database itself decides who may read and change which rows. In Supabase this is called Row Level Security, or RLS for short. If RLS is off, anyone with the public key, which sits in your website, can request entire tables. Firebase has the same issue with its Security Rules: a rule that allows anyone to read and write is handy while building and an open door after launch.

You can check this yourself: open your app in the browser, open the developer tools and search the loaded JavaScript for words like service_role, sk_live or sk-. If you find a secret key, revoke it with the provider and create a new one. Just removing it from the code is not enough, because the old key may already have been copied. Then check in the Supabase or Firebase dashboard which tables have no rules.

Also watch out for settings with a prefix like VITE_ or NEXT_PUBLIC_. Those are deliberately put into the code for the browser. A secret key with a name like that is visible to everyone, however neatly it sits in a configuration file.

Logging in is not the same as access control

Many founders think: my app has a login screen, so it is secure. But logging in only proves who someone is. What that person is allowed to see and do is a second step, and AI tools forget it now and then. It is not a small problem either: in the 2025 OWASP Top 10, the best-known list of security risks for web apps, broken access control is number one.

A common example: your invoice overview is at an address ending in /invoices/1042. A customer changes that number to 1041 and sees someone else’s invoice. The app checks that the customer is logged in, but not whether the invoice is theirs.

Testing this takes a quarter of an hour. Create two test accounts, log in with the first one and copy the addresses of a few pages with its own data. Log in with the second account and open those addresses. If you see the data of the first account, you have a leak. Do the same with admin pages: open them as a regular user and while logged out.

Packages and updates: the work after launch

Only a small part of your app is code written for you. The rest is hundreds of packages written by others: for logins, payments, dates and so on. New vulnerabilities keep being found in those packages. Once one is known, it gets a CVE number and is listed in public databases. Attackers can read those too, and they search automatically for sites that still run an old version.

It is no coincidence that ‘Software Supply Chain Failures’ is new in the 2025 OWASP Top 10: problems in the packages and tools your app is built with. An app that was secure at launch does not stay that way on its own six months later.

What helps: let a tool like npm audit, Dependabot or Renovate check your packages automatically, and apply critical updates quickly. Test after every update that your app still works, because an update that breaks something is exactly why people put updates off. That is why my maintenance plans include a daily check for known vulnerabilities and package updates, so you do not have to think about it.

When things do go wrong: backups, logs and monitoring

No app is a hundred percent secure. So the question is not only how to prevent a problem, but also how quickly you notice it and how you recover. Three things make the difference.

Backups: make automatic backups of your database and keep them somewhere other than your app. A backup you have never restored is a hope, not a plan, so try it at least once. Logs: record who logs in when and what goes wrong, without putting passwords or other sensitive data in those logs. Without logs, you cannot see afterwards what happened. Monitoring: have a service check your app every few minutes and warn you when it is unreachable or suddenly throws a lot of errors.

Also look at what your app shows when something fails. A user gains nothing from a message full of technical details, but an attacker does. Show the user a tidy message and put the details in your logs.

Personal data and the GDPR

If your app processes names, email addresses or other personal data, the GDPR applies. This is not legal advice, but a few basic questions belong in every security review. Do you collect only what you really need? Do you know which country your database is in? And do you have a data processing agreement with the services that store data for you, such as your hosting and your database?

If things go wrong and personal data leaks, in many cases you have to report it to the data protection authority within 72 hours. You can only do that if you notice in time yourself, and if you can work out which data was exposed. That is another reason why logs and monitoring are not a luxury.

Check it yourself or have it checked?

The two-account test, searching for keys in the browser and going through your database rules are things you can do yourself. What is harder: judging whether the rules that are there are actually right, whether the server really checks what the screens promise, and which packages are a problem. For that you need to be able to read the code.

That is what my App Check is for. For €600 (excl. VAT) I review one app of up to 15 screens, with one database and up to 3 connections, such as payments, email or signing in with Google. Within 5 working days you get a report in plain language, with the risks ranked red, orange and green, and we go through it together in 30 minutes. If you then start a maintenance plan within 30 days, I credit the €600 in full.

To be clear: an App Check is not a formal penetration test. If you need one, for example for a certification or because a large customer asks for it, a specialised firm is the right party. After an App Check, you will go there better prepared.