Monday morning, my first stop was customer data
At 9 a.m. on Monday, I opened the dashboard in a Hangzhou café and habitually checked customer forms and message records. Then I saw a report that some Lovable apps had exposed passport information and more than 200,000 private messages. My hands tightened around the coffee: could one of our no-code tools be leaving IDs, contracts, or chat logs out in public? I had never checked this before. I had messed this up too, assuming that once an app was “built,” it was safe.
What it is, and who has hit it
This was not about whether Lovable could build a website. Security researchers had inspected public Lovable apps and found that some pages or APIs returned sensitive information submitted by users, along with private conversations. Security researcher Crissy Field published the investigation on her own site. The discussion also appeared on Hacker News and briefly collected hundreds of replies.
I would not read this as “use it and you’re hit.” The practical move was to open our own customer pages, forms, share links, and download entries one by one, then view each result from different devices. My friend Chen Jia, a freelancer in Chengdu, only discovered the problem after building a registration page for a client: an old test link was still sitting in the chat history. She replaced the link that day and asked the developer to check whether submitted content was publicly visible. Her story reminded me that the danger is not always in the tool; it is often in an entrance we forget to close.
My replication: $0, about 90 minutes, low barrier
Money: no tools to buy, so $0. Time: about 90 minutes. Technical barrier: enough to navigate a webpage, copy a link, and inspect a form; no coding required. First step: open the project list in the Lovable dashboard, find the app with the most customer data or messages, and click “Preview” or “Open” in the upper-right corner. Open the public page in an incognito window, then inspect the submission entry points, share buttons, and file links one by one.
Next, test as an ordinary visitor: can you see other test data, file addresses, or conversation content? Then check public access, database access, and sharing permissions under project settings. If I am unsure, I ask the developer to test one specific condition: “Can a visitor read customer-submitted content?” If exposure is confirmed, I pause public access first, export the necessary records, delete old links, and then decide whether to repair the project, migrate it, or shut it down.
Not everyone needs this process. If an app is only a portfolio page with no customer data, checking now is optional; there is no reason to overhaul a system in a panic.
Match the check to my stage
If I am just starting and the site only shows my portfolio, I do one “stranger visitor” pass. It takes about 30 minutes, with no real identity documents uploaded and no sensitive information placed in public links.
If I already have one or two clients, I run the full check: test every form, file, and share link, list the exposed items, close old entry points that day, and send clients a short change notice.
If I am scaling, I have the developer turn the check into a fixed checklist and review it weekly. Once client volume grows, I revisit permissions, retention periods, and backups. This deserves attention, but it does not require me to stop everything else. I start by opening that public preview link.