An office window left ajar in the evening above a work desk with a half-closed laptop

September 5, 2026 · 6 min read

By Thomas Cohen, founder of Maestro

Exposed customer data: a two-minute test for an AI-created application

Your application displays a login screen, so your customer data is protected. Providers repairing these applications describe the opposite across three different samples. Three checks you can perform tonight, and three questions for whoever builds it.

A provider repairing no-code applications writes on Reddit (r/lovable, July 2026) that around a third of those reviewed leave customer data accessible to any visitor, and that it takes two minutes to establish this. Your AI-created application shows a login screen; that says nothing about what the database protects.

around one thirdof Lovable applications reviewed by a provider (r/lovable, July 2026)
more than 30no-code applications repaired in a year by another provider (r/nocode, June 2026)
at least 30access keys found in plain text by a Hacker News commenter (February 2026)

What those repairing these applications see

Two providers making their living repairing no-code applications describe the same failure. The first says they rescued more than thirty in a year (r/nocode, June 2026) and found none protecting all data types: one always remains open from construction and is never closed. The second, reviewing Lovable applications, counts around a third whose database answers whoever requests it (r/lovable, July 2026). A Hacker News commenter claiming to audit such sites daily adds that they found at least thirty access keys left in plain text (February 2026). These three voices sell security services: their figures describe their customers, not the whole market. Still, they concern three distinct samples and tell the same story.

The login screen protects nothing

Your application has a display on one side and a database on the other. The display decides what appears on screen; the database decides what comes out when asked. When nobody has written rules table by table, who may read customers, who may read orders, the database answers every request the same way, while the screen keeps looking normal. An application can therefore run for months, take payments and serve real users while the back door remains open. Security is decided in the database, table by table, and the screen cannot compensate.

Three checks you can do tonight

First: open your application's public address in a private browsing window without logging in, and note every page displaying something real, a list, customer record, dashboard or settings page. Second: create two test accounts with different email addresses, enter recognisable data in each, then verify from the first that nothing from the second appears anywhere, including searches and exports. Third: request a data export from an ordinary account and read its contents; an export more generous than the requesting account signals a missing rule. These three actions take place on your own application, in a quarter of an hour, without installing anything.

Three questions for whoever builds it

Ask them in French, whether to an agency, freelancer or agent team working for you. One: does each database table have its own written access rule, and what is it? Two: when an account requests data it does not own, what does the server return and which test proves it? Three: what prevents a demonstration visitor from writing into the database serving my real customers? A reassuring answer naming no rule counts as no answer and deserves the question again in writing. Notice these questions use everyday French: they require someone willing to answer clearly, as the five AI development traps already show.

What a method changes, and what it does not

At Maestro, access permissions are decided in the requirements before construction: who sees what, who changes what, what an unauthenticated visitor can reach. Marcel then divides the work into stages, and Félix writes each stage's tests before a line of code exists, forcing the access rule to be stated explicitly rather than assumed. None of these safeguards makes an application invulnerable, and we are poorly placed to claim otherwise: a beta tester found a visible database key in our own code in August, since corrected. A method reduces the number of places where a rule is missing. It does not replace review by someone whose profession is security.

In practice

Perform the three checks tonight on your production application, in order, and write your findings on paper. If one worries you, turn off public access while you investigate: an application offline for two days costs less than a circulating customer file. If you are still building, add the line ‘who may read what’ to your requirements before the first construction stage and keep it in view at every approval. Our Your data page details where yours lives when you work with Maestro.

Back to the journal

Take the baton.

Leave your email to try Maestro in the first waves.

The beta opens in waves. People on the list try it first, and Maestro stays free throughout the beta.

The beta is currently available on macOS 13 or later. Your answer helps us plan other versions.

Your email is only used to let you know when access opens. Nothing else, we promise.