In one business day, find out what anyone can see and do in your Lovable app without logging in
Lovable gets a working app live fast, but what anyone can see without logging in depends on access settings that are easy to miss. To show how the check works, I built a booking app in Lovable for a mobile dog grooming business, published it, and checked it the same way I check client apps: first from the outside, using only the public link, then through every main step a customer and the owner take on a phone. Using only the public link, I found a way to take over the owner account and see every customer's phone number and home address. It's an easy mistake to make. While building the app, I asked Lovable for a one-time "Make me the owner" button, and sign-up was still open to anyone. The full report is below: 7 issues, all fixed and retested on the working app.
What I check
From the outside, using only the public link. I look at your app the way anyone without a password would: can anyone see customer data without logging in, can anyone sign up and get access they shouldn't have, are uploaded files open to the public, and is there a secret key left in the page code that unlocks your customer data. The check is view-only: I don't change or copy anything.
On a phone, as your customer and as the owner. I go through the main steps on a phone screen: booking, rescheduling, late cancellation, the waitlist, reminders and the owner dashboard.
This check doesn't include a line-by-line review of the code and the access settings for your data. That's the full review, and the Walkwren sample shows what it covers.
The short version: what I found
| 1 | Any visitor could become the owner and see every customer | critical | fixed |
| 2 | A freed-up slot went to a client whose visit didn't fit, and they were told "someone was faster" | lost revenue | fixed |
| 3 | One person got several "you didn't finish booking" messages | could land you in spam | fixed |
| 4 | The main Book button needed two taps | lost bookings | fixed |
| 5 | Links in emails and texts didn't open | customers can't click through | fixed |
| 6 | Screens said "sent" before a message had actually gone out | hurts trust | fixed |
| 7 | An error on the first load of the owner page | minor | fixed |
| Customer data without a login, secret keys in the page code, public files | nothing found | ||
1. Any visitor could become the owner
What I found. The public sign-in page offered "First time? Create the owner account", and the dashboard had a one-time "Make me the owner" button. Sign-up was open to everyone and no owner account existed yet, so the first person to sign up would have become the owner.
What it means for the business. Anyone with the link gets every customer's name, phone number and home address, the schedule and the message history, and the real owner is locked out of their own app.
What was fixed. The link and the button are gone, sign-up is turned off, and nobody can make themselves the owner from the app anymore.
How it was retested. The sign-in page now only lets people log in, and the login settings show that sign-up is turned off.
2. Freed-up slots stayed empty
What I found. After a cancellation, the app offered the free 45 minutes to a waitlisted client whose dog needs 100. They tapped "Take it", the booking failed, and the page said "Already taken, someone was a little faster." Nobody had taken it.
What it means for the business. The one feature meant to fill empty slots left them empty and told the customer something untrue. Every slot like that is a visit that didn't happen.
What was fixed. Offers now go only to people whose visit fits the gap, counting the area, travel time and closing time. The offer shows their own service and how long it takes, and if something fails, it gives the real reason.
How it was retested. Cancel, offer to a client whose visit fits, "Take it", then "It's yours!", and the visit shows up in the owner's week.
3. The same reminder, sent several times
What I found. Every booking someone started created a new lead, so a person who started twice from the same number got several "Still want that groom?" messages.
What it means for the business. Customers get annoyed, and email and text providers flag senders who repeat themselves, so your messages start landing in spam.
What was fixed. Leads are merged by phone and email. One person gets at most one reminder every 7 days, and none after a finished booking.
How it was retested. Running the reminders twice in a row sends nothing twice.
4. The Book button needed two taps
What I found. The first tap on "Book a groom" only checked the ZIP code, and nothing moved on the screen. A customer on a phone would think booking was broken.
What was fixed and how it was retested. One tap checks the ZIP code and opens the next step.
5 and 6. Message wording
What I found. Links in emails and texts were missing the site address, so they didn't open. And screens said "sent" while the messages were still waiting in the outbox.
What was fixed and how it was retested. Messages now have full links to the site. Instead of "sent", the screens say "handled" and "ready to send", with a note that real sending connects to the business's own email address.
7. An error on the first load of the owner page
What I found. On the first load, the server and the browser drew different versions of the dashboard, and the browser console showed an error. The owner never sees it, but errors like this can cause glitches on the page later.
What was fixed and how it was retested. The server and the browser now draw the same first screen, and a clean load shows no errors.
The outside check: a log for your developer
The short version for the owner: customer data stays hidden without a login, there are no secret keys in the page code, sign-up is turned off, and Lovable's own security scan found no issues.
The log below is exactly as it ran. Every request is read-only and uses the same public key any visitor's browser already gets. Values are never printed, only whether a table answers and how many rows it shows.
App: https://bramblewash-bookings.lovable.app
Backend: Lovable Cloud (found in the page code, 29 script files)
Secret keys in page code ........ none
Tables answering without login .. 15 checked · 0 rows visible in all 15
Sign-up ......................... disabled
Email confirmation .............. on
Functions exposed by name ....... 5 (not called — calling could change data; the builder
confirmed in the database that visitors can't run the admin ones)
Lovable security scan ........... 0 issues
Common questions about the check
- Do you need access to my app or my data?
- No. The public link and your written permission are enough. I only look at what any visitor can see, I don't change anything, and I never copy customer data.
- What if you don't find anything serious?
- You still get the full report, showing exactly what was checked and what passed.
- Who fixes what you find?
- Your choice. You can make the fixes yourself from the report, or have me make them as a separate stage and check the app again afterward.
The same check for your app
A report on your working app within one business day, from $150. For every issue, you see what I found, what it puts at risk and how to fix it. You can make the fixes yourself or have me make them as a separate stage, and then I check the app again. I work only with your written permission. The check is view-only, and I never copy your customers' data.
The easiest way to start: send me the link to your app and one sentence about what your customers do in it. I'll tell you what I'd look at first and what the check would cost. No commitment.
Demo app: bramblewash-bookings.lovable.app. Tap "Open Maya's dashboard (demo)" to see the owner side.
P.S. If your app already takes bookings or payments, have it checked before the first few hundred customers sign up. Fixing access now costs less than explaining it to customers later.