Secure
No-code does not mean no security
No-code platforms are safe on one condition: that access rules are written. Otherwise, the database is open to everyone.
In 2018, the security firm Appthority analyzed thousands of mobile apps and found that more than 3,000 of them left their Firebase database open, with no authentication. The result: more than 100 million records accessible, more than 113 GB of data, including passwords, health information, and banking data (source: TechTarget, Appthority, 2018).
Firebase was not at fault. Neither were the apps. What was missing comes down to one sentence: nobody had closed the database door.
The no-code misunderstanding
Building fast creates a misleading sense of security. The app displays, the data saves, everything works. You conclude it is "done." But a modern database (Firebase, Supabase, and others) is open by default at the level where you configure it: it is up to you to write the rules that say who is allowed to read and write what. Without those rules, ease of building is paid for in exposure.
The Supabase case: the line that changes everything
Many applications built today, including on Lovable, rely on Supabase. Supabase offers a precise mechanism for this: RLS (Row Level Security), security row by row. Enabled and written correctly, it ensures a user only reads their own rows. Forgotten or misconfigured, the opposite happens: the entire table becomes readable by anyone who knows how to query it.
The trap is that the two versions, the safe one and the leaking one, look the same on screen. The application behaves identically. The difference only shows if you go looking for it.
Built fast is not secured fast
No-code and low-code have made building accessible, and that is good news. But they have not removed security: they have moved it into configuration. An application shipped in a week deserves exactly the same access control as an application developed over six months. The time saved is real. The exemption from verification does not exist.
What I recommend
If your application stores customer data, have your access rules checked before scaling up, not after the incident. The audit looks precisely at this point: are the rules enabled, and do they hold up when put to the test.