A self check you can run yourself, before you pay anyone

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.

Book a Security Review Call (03) 9003 0111

Realistic ROI

20 minutes

Is enough to run the six checks below

No coding required. You need a browser, a second email address, and your hosting or database console login

3 faults

Cause most serious findings in AI built apps

Row level security disabled, API keys in client side code, and permission checks that live only in the interface

Minutes, not weeks

Is how fast a key committed to a public repository gets found

Public code is continuously scanned by researchers and opportunists. Keys shipped in a browser bundle are less instantly harvested but equally public, so treat both as known

Point in time

Is the only honest claim any review can make

A review describes what was true on the day it ran. It is not a certificate and it does not stay true by itself

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.

Ten minutes, highest value

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.

Three minutes

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.

Three minutes

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.

Two minutes

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.

Two minutes

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.

Five minutes

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.

FAQ

Is Lovable itself insecure?

No more than a text editor is. Lovable, Bolt, Replit, v0, Cursor and Claude Code are all capable of producing sound code, and all of them will happily produce unsound code if that is what the conversation led to. The pattern is not a flaw in any one product, it is that a prompt describes features and almost never describes the boundaries: who may see what, what happens when input is hostile, what the server should refuse. The tools have also improved noticeably at prompting users about these issues, which helps, and it still does not replace someone checking.

What is row level security and why does everyone mention it?

It is a database feature that lets each row carry rules about who is allowed to read or change it, enforced by the database itself rather than by your application. It matters because without it the only thing stopping a person from retrieving every record is that your front end chose to ask for a filtered set. Anyone can open the browser tools, copy the request and remove the filter. More often than not it was never switched on at all, because a new table starts unprotected until someone enables it, and sometimes it gets disabled during development because it makes early building fiddly and is never restored. Either way, that is exactly why check five above exists.

I found a key in my JavaScript. How bad is that?

It depends entirely on which key. Publishable and anonymous keys are designed to live in a browser and their presence is expected, which is why the naming usually says so. Secret keys, service role keys, and anything the provider documentation tells you to keep on a server are a real problem, because they typically carry far more power, often bypassing the access rules you have set up. Rotate any such key today in the provider dashboard, then move that call to a server side route so the replacement never reaches a browser. Do the rotation even if you have no evidence of misuse.

My app has only ten users, all friends. Does any of this matter yet?

Probably less than you fear, and this is where we will talk you out of spending money. If there is no personal information beyond names and emails, no payments, and every user is somebody you know, then running the self check and fixing anything obvious is a reasonable place to stop. The moment to get serious is when strangers can sign up, when you begin holding information that would embarrass someone if it leaked, or when you take a payment. Book the review when one of those becomes true rather than because a page on the internet made you anxious.

If I pass all six checks, is my app secure?

No, and this is the most important sentence on the page. Passing means the faults that most commonly appear in AI built applications are probably not present, which is genuinely good news and is not the same as being secure. The self check does not examine your password reset flow, your webhook endpoints, your dependency tree, your storage permissions in detail, or your business logic. More fundamentally, any check is a point in time observation. Your position changes with the next deployment, the next dependency update and the next platform default change. Nobody honest, including us after a full paid review, will describe your application as secure.

Can I just ask the AI tool to fix the security problems?

Sometimes, and with real care. Asking a coding assistant to enable row level security and write policies for your tables can work well, particularly if you first write down the ownership model in plain English and hand it that. Where it goes wrong is that the tool will confidently report success without any way to verify it, and it cannot test the thing that actually matters, which is whether a different real account can still reach the data. So use it to do the work if you like, then rerun the second account test yourself. Verification by a human who understands the intent is the part that cannot be delegated.

How do I know a security consultant is not just scaring me?

Ask three questions. Will you tell me the fixed fee for the review before we start, will I own the findings and be free to take them to another developer, and is the repair quoted as a separate document afterwards. Anybody who answers yes to all three has taken away their own incentive to inflate the list. Then read the report itself: each finding should tell you exactly how it is reached so you can reproduce it, and some findings should be marked as fine to leave. A report where everything is critical is a sales instrument. Call us on (03) 9003 0111 and ask us those questions too.

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.