Is My Lovable App Secure? Here Is How to Find Out Yourself
The honest answer is that nobody can tell you from the outside, and anybody who says yes or no without looking is guessing. What can be said is that applications generated by Lovable, Bolt, Replit, v0, Cursor and similar tools tend to fail in a small and very consistent set of places, so a founder with no coding background can check the most important ones personally in about twenty minutes.
That is what this page is. Six checks you can run today on your own application, what a pass and a fail look like for each, and what to do if one fails. If they all pass you are in better shape than most, and you should feel free to stop reading and get back to work. If two or three fail, that is normal, it is fixable, and it is worth dealing with before you have more users rather than after.
Realistic ROI
Four Things Worth Understanding Before You Panic
The risk here is real and it is also specific. Knowing which parts are actually dangerous stops you from either ignoring it or overreacting to it.
Lovable is not the problem, the missing brief is
These tools build what the prompt describes, and prompts describe features. Nobody writes "and make sure a signed in customer cannot read another customer’s records by changing a number in a request", so nothing in the generated code enforces it. The interface hides the gap perfectly because your menu only ever shows your own data. Blaming the tool is beside the point. The useful move is to add the checks the brief never contained, which is a short, defined piece of work rather than a rebuild.
Signing in is not the same as being allowed
Most AI built applications handle authentication competently, because logging in is a visible feature that gets described and tested. Authorisation, which is the question of what a signed in person may then do, is invisible until it fails. Hiding an admin button from ordinary users is presentation. The protection has to sit on the server that answers the request, and in generated code it very often does not. This distinction explains the majority of the serious findings in this category.
Anything in the browser is public, including your keys
People are frequently surprised by this, so it is worth stating plainly. Every line of JavaScript your site sends to a visitor can be read by that visitor, and it is routinely collected and scanned automatically. If a key for a payment provider, an email service, a storage account or a model provider is in that bundle, treat it as published. Publishable keys designed for browser use are fine and exist for exactly this reason. Service or secret keys are not, and their exposure ranges from an unexpected bill to somebody sending mail as you.
Security is a state that decays, not a box to tick
Even after a careful review and a set of fixes, your position changes the next time you deploy, the next time a dependency updates, and the next time a platform changes a default. That is why nobody honest describes an application as secure after an audit, and why a certificate would be misleading. The realistic goal is to close the serious gaps, then have enough logging and error reporting that you notice the next problem yourself rather than hearing about it from a customer.
The Twenty Minute Self Check
Six checks, in order of how much they matter. You need a browser, a second email address so you can create a second account, and access to your hosting or database console. No coding.
Check 1: the second account test
Sign up a second account with a different email in a private browsing window, and put a piece of obviously identifiable data into it. Now, as that second account, try every way you can think of to reach the first account’s data: search boxes, list screens, any page that shows a total or a count, any export or report. You should never see it. If any screen shows you data belonging to the other account, stop and treat it as urgent, because that is not a display bug and real users will find it.
Check 2: change the number in the address bar
Open one of your own records and look at the address. If it contains an identifier, particularly a simple sequential number, change it to a neighbouring value while signed in as your second test account. A correctly built application returns a not found or not allowed message. A vulnerable one cheerfully shows you a record you do not own. Try the same trick on any page that generates a document, an invoice or a download link, because those are frequently protected less carefully than the screens.
Check 3: look at what the server actually sent
Press F12 to open developer tools, choose the Network tab, then reload a page that shows a small amount of information about a person or an order. Click the request that fetched the data and look at the response. You are checking whether the server sent only what the screen displays, or the entire record including phone numbers, email addresses, internal notes, costs or other people’s rows. Anything sent to the browser is available to the person using it, whatever the screen chooses to display.
Check 4: search your own site for keys
With developer tools open, use the Sources or Search panel and search the loaded files for telling fragments: sk_, sb_secret_, service_role, secret, api_key, and the name of any provider you pay, such as your payment or email service. A publishable or anonymous key appearing here (sb_publishable_, or the older anon key) is expected and by design. A secret key, a service role key or anything labelled secret is a genuine finding. If you find one, rotate it in the provider’s dashboard today, then work out which server side route the call should have gone through.
Check 5: open the database console and look at the rules
If your app uses a hosted database such as Supabase, sign in to its dashboard and find the table listing. Most consoles show, next to each table, whether row level security is enabled and how many policies exist. Any table holding customer records, orders, messages or files with that protection switched off is relying entirely on your front end to ask nicely for the right rows. Zero policies on a table with data in it is the most common serious finding in this whole category, and it is often a same day fix.
Check 6: be rude to your own forms
Type an apostrophe and a couple of angle brackets into a name field and save it, then look at the record on other screens. Upload a file that is much bigger than you expect anyone to use, and a file type your app does not want. Sign out in one tab, then use a saved link in another. Press back halfway through a form and resubmit. You are looking for two things: anything that breaks and anything that appears to succeed but silently saves nothing. Both are common and both are cheap to fix once you know they exist.
How to Read Your Results
| Task | Traditional | What a pass looks like | Notes |
|---|---|---|---|
| Second account can see your data | Reachable from an ordinary screen | Not found or not allowed, every time | The most serious result on this list. Do not deploy new features until it is closed. |
| Changing an identifier in the URL | Shows a record you do not own | Refused by the server, not just hidden | Check documents and download links as well as screens. They are protected less often. |
| What the network response contains | The whole record, plus fields never shown | Only the fields the screen actually displays | Rarely catastrophic on its own, and it is what someone collecting data would use first. |
| Keys visible in the browser bundle | A secret or service key is present | Only publishable or anonymous keys | If you find a secret key, rotate it today. Assume it is already known. |
| Row level security in the console | Disabled, or enabled with no policies | Enabled with policies matching ownership | Enabled with zero policies blocks everything, so the app breaks. The danger is what happens next: switching it back off, or wiring the front end to a service key that bypasses the rules entirely. |
| Odd characters in form fields | Something breaks or renders strangely | Stored and displayed exactly as typed | Usually a reliability fault. Occasionally the front end of a more serious one. |
| Oversized or wrong type uploads | Accepted, or fails with no message | Refused with a clear explanation | Also check whether uploaded files have public URLs that anyone can guess or share. |
| Using the app after signing out | A saved link still returns data | Redirected to sign in, with no data sent | Test in a private window. Cached pages in your normal browser will mislead you. |
What to Do With What You Find
If a check fails on personal information, slow down before patching
Australian privacy obligations can require you to assess whether personal information was actually accessed without authorisation and, in serious cases, to notify affected individuals and the regulator within defined timeframes, and the assessment itself has a 30 day limit. It relies on logs, which are far easier to interpret before the configuration changes. So write down exactly what you found and when, and check whether your database or hosting provider retains access logs. Whether the Privacy Act reaches you at all turns on turnover and on what you hold: as at August 2026, a business turning over $3 million or less is usually outside it, unless you handle health information or fall into one of a short list of other categories. Establish that first, then get advice on whether the notification threshold is met. Patch first and ask later is the sequence that destroys your own evidence.
Rotate exposed credentials before you do anything else
A key that has been published in a browser bundle or committed to a public repository should be treated as known to strangers, whether or not you can see evidence of misuse. Rotation in the provider dashboard usually takes minutes and it is the highest value thing you can do in the first hour. Include payment providers, email senders, storage, model providers and webhook signing secrets. Then work out which of those calls needs to move behind a server route so the replacement key never reaches a browser.
Do not turn on row level security blindly and hope
Switching the setting on without writing policies typically blocks everything and takes your application down, which then tempts you to switch it straight back off and never revisit it. The right sequence is to write down your ownership model first, in plain English, one line per table: who may read this, who may write it, and what makes a row theirs. Then implement policies to match, test with your second account, and only then rely on it. Half an hour of writing saves a bad afternoon.
Passing all six checks does not mean you are secure
This list covers the faults that occur most often in AI built applications, which is not the same as covering everything. It does not test your password reset flow for takeover, your webhook endpoints for forged requests, your dependency tree for known vulnerabilities, your file storage permissions in detail, or anything about your business logic. A clean self check means the common serious faults are probably absent. It is a genuinely good sign and it is not a clean bill of health.
Be careful who you send your findings to
If a check fails, you now hold a written description of how to reach data in your own application. Keep it out of public channels, community forums and support chats where the transcript may be read by others. Share it with a developer you have an agreement with, over a private channel, and never paste live credentials in the same message. It sounds obvious and it is a common way for a fixable problem to become a public one.
Fix, then get logging, before you build anything new
The single most useful improvement to an application that already has users is not another feature, it is being able to see what happened when something goes wrong. Basic error reporting and a record of failed requests turns future incidents from guesswork based on a customer’s description into a five minute diagnosis. Put that in during the same piece of work as your fixes, while somebody is already in the codebase, rather than promising it for later.
Where Yes AI Fits, and Where We Do Not
A fixed fee review when the self check is not enough
If the checks above failed, or you want confidence beyond the common faults, we run a structured review across authentication and authorisation, database rules, exposed secrets, input handling, error handling and data exposure. Fixed fee, agreed in writing before we start, delivered as a ranked report you own and can act on without us.
The repair is always quoted separately
We never bundle the audit and the fix into one price, because that arrangement pays whoever is doing the finding to find more. You get the findings first, then a separate quote against a specific list, which you are free to price against the market or hand to your existing developer. It is worse for our margin and it is the only structure that makes a report credible.
We will tell you when you do not need us
Plenty of early stage applications with a handful of friendly users and no personal information genuinely do not warrant a paid review yet. If that is your situation we will say so on the call and point you at the two or three things worth doing yourself. We would rather have that conversation than take a fee for reassurance you could have obtained in twenty minutes.
Be honest with yourself about what you actually want
A good share of people who ask whether their app is secure really want somebody to finish building it, and the security worry is the thing that finally prompted the call. That is a completely reasonable position, and it is a much larger engagement than a review with a different shape and price. Naming it on the first call saves everyone the discovery three invoices in.
If the Self Check Fails, Here Is the Sensible Order
Five steps. The first two you can do today without hiring anyone.
Write down exactly what you found
Which check failed, the steps that reproduce it, the date and time, and which tables or screens are involved. This becomes both your fix list and, if personal information is implicated, the start of the assessment record you may need.
Rotate anything that was exposed
Every credential you found in the browser bundle or a public repository, plus anything you have ever pasted into a chat window or a prompt. Minutes of work in the provider dashboards, and it closes the fastest moving risk on the list.
Write the ownership model in plain English
One line per table: who may read it, who may write it, and what makes a row belong to someone. This is the document that makes database policies straightforward to implement and to verify, and it is the thing that is almost always missing.
Get a proper review if the stakes justify it
If you hold personal, financial or health information, if you have paying customers, or if two or more checks failed, a structured review across all six areas is worth the fixed fee. If none of those apply, fixing what you found yourself may genuinely be enough for now.
Fix, verify by reproducing, and add logging
Each fix tested by rerunning the exact check that failed, deployed with a way to roll back, and error reporting turned on so the next problem is visible. Then confirm in writing what remains unfixed and deliberately accepted, so it is a decision rather than an oversight.
Related Reading
Vibe Code Audit
The fixed fee review: scope, report contents and turnaround.
Fix My AI Built App
What typically breaks in AI generated applications and why.
Website Security Audit
The equivalent review for a public marketing website.
AI and Data Privacy in Australia
What Australian privacy obligations mean for a small software business.
Penetration Testing
Adversarial testing, a different exercise from a code review.
Claude Code Consulting
Using AI coding tools with structure and review around them.
FAQ
Run the Checks First, Then Decide
If the six checks above came out clean and your users are few, you probably do not need us yet, and we will say so. If two or three failed, book a call and we will tell you plainly what it takes to close them. Fixed fee review, findings yours either way, repair quoted separately.
All discussions held in confidence. Australian-based consultants.