In May 2025, a flaw in apps built with the AI app builder Lovable was given an official vulnerability record, CVE-2025-48757. The record describes weak database rules that let anyone on the internet read or write data in the sites Lovable generated. Lovable disputed the record. Its position, as the US National Vulnerability Database records it, is that “each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.”
That sentence is the one to remember if you are a founder with an AI-built app. In that dispute, at least, the maker of the tool says the data in your app is your responsibility. Once the app takes payments and personal details, the law agrees.
Our verdict is that an AI-built app can be good enough to take payments. Whether yours is comes down to five checks, none of which the tools run for you. For a small app, we would expect them to take an afternoon with whoever built it.
These are not rare mistakes
The research on AI-written code points the same way. Veracode, a company that sells code-security testing, tested more than 100 AI models across Java, Python, C# and JavaScript in 2025 and found that “45% of code samples failed security tests”. Its update in March 2026 found security pass rates “stubbornly stuck at approximately 55%”, regardless of how new the model was. That is a vendor’s own test on small tasks, not whole apps, but the documented incidents below show the same gap in real products.
1. Can one customer see another customer’s data?
This is the flaw behind the Lovable and Moltbook incidents.
Lovable. Matt Palmer, one of the people who found the issue, published the scan results on 29 May 2025. Of 1,645 Lovable apps analysed, 170 (about 10.3%) had “inadequate RLS settings”. RLS, or row level security, is the database rule that stops one user reading another user’s records. The exposed data included “names, phone numbers, API keys, payment details” and more, and the scan only looked at each app’s homepage.
Moltbook. In a report published on 2 February 2026, the security firm Wiz described how Moltbook, a social network for AI agents, had left its database open. The exposure covered 35,000 email addresses and 1.5 million API keys. Wiz explained that the database’s public key is safe only when row level security is set up, and “without RLS policies, this key grants full database access to anyone who has it.” In Moltbook’s case, “this critical line of defense was missing.” Wiz’s timeline shows Moltbook made its first fix on the day Wiz contacted it.
In the language of OWASP, the security community’s standard list of web risks, this is broken access control, first on its 2025 Top 10.
The check: create two test customer accounts. Log in as one and try to open the other’s orders, invoices or profile, by changing the number in the web address or by asking the database directly. If anything loads, stop and fix it before launch.
2. Do card details ever touch your app?
The simplest way to make payments safe is to make sure your app never sees a card number.
Stripe’s security guide says businesses can use “one of our low risk payment integrations to securely collect and transmit payment information directly to Stripe without it passing through your servers, reducing your PCI obligations”. For integrations built on Stripe Elements or Checkout, Stripe says it provides “assistance in completing their PCI validation form”. PCI DSS is the card industry’s security standard, and “Anyone involved with the processing, transmission, or storage of card data must comply”. Stripe warns that a business handling card data directly “might be required to meet more than 300 security controls”.
The check: confirm that card details are typed into a Stripe-hosted page or a Stripe Element, and that no card number ever appears in your own database, logs or code. If the builder wrote its own card form, replace it.
3. Are the secret keys actually secret?
A Stripe secret key gives “access to all Stripe APIs and resources without restriction”, and Stripe warns that “If a fraudulent actor obtains your secret key, they can harm your business.” Its guidance is blunt: “secret keys must stay in your server environment”, “Never put secret API keys in source code”, and “Bad actors continuously scan public repositories for Stripe API keys”. It adds that “Even private repositories can be exposed”.
A key pasted into code that runs in the customer’s browser can be read by anyone who visits the app.
The check: ask whoever built it to show you where each secret key is stored. The answer should be a setting on the server, never a file in the code. Then search the code for the start of a Stripe secret key, sk_live_. It should not appear.
4. Does the app check that a payment really happened?
Stripe tells your app that a payment has succeeded by sending it a message, called a webhook. Stripe’s documentation says: “Stripe signs every webhook event by including a signature in the Stripe-Signature header. Verify this signature using our official libraries or manually to confirm that the event wasn’t sent or modified by a third party.”
An app that does not verify that signature takes any message that claims to be from Stripe on trust. Someone who finds the address could tell your app an order was paid when it was not.
The check: ask to see the code that receives Stripe’s webhooks, and confirm it verifies the signature with the webhook signing secret before doing anything else. Then send it a fake message without a signature, and check it is rejected.
5. Are test and live kept apart, and can you restore a backup?
In July 2025, the investor Jason Lemkin was building an app with Replit’s AI agent. On 18 July, Lemkin posted that “@Replit goes rogue during a code freeze and shutdown and deletes our entire database”. The story had a better ending than it first seemed. Lemkin wrote that Replit had said a rollback was impossible in this case, and later that day posted: “It turns out Replit was wrong, and the rollback did work.” Lemkin’s lesson was direct: “But you can’t overwrite a production database.” And, in the next line: “And you can’t not separate preview and staging and production cleanly.”
The check: make sure there are separate test and live databases, and that the AI tool and its agents cannot change the live one without a person approving. Then restore a backup of the live database into a test copy and confirm the data is all there. Until you have restored a backup, you do not know you have one.
What the law expects once you take payments
Once your app holds customers’ personal data, UK GDPR applies. Article 32 requires “appropriate technical and organisational measures to ensure a level of security appropriate to the risk”, including “a process for regularly testing, assessing and evaluating” them. If data is exposed, the ICO’s guidance is that a reportable breach must be reported “within 72 hours of becoming aware of the breach, where feasible.”
If you sell to consumers online, the Consumer Contracts Regulations 2013 also set out what you must tell them before they buy. That includes your identity, the geographical address you trade from and, where available, your phone number and email, and “the total price of the goods, services or digital content inclusive of taxes”, with any delivery charges.
None of this depends on how the app was built. A founder with an AI-built app has the same duties as one with a team of developers.
What to do before you switch payments on
Run the five checks above, or have someone independent run them. For a small app, that is an afternoon’s work.
Use Stripe’s hosted Checkout if there is any doubt about the payment form. It is the quickest way to keep card numbers out of your app.
Write down who you would call if customer data leaked, and keep the ICO’s 72-hour window in mind.
Keep the AI tool away from live data. Let it change the test version, and move changes to live yourself.
We have written more about the wider problem in vibe coding’s security debt.
Frequently asked questions
Is an app built with AI safe to take payments?
It can be, but the AI builder does not make it safe for you. The common failures are customers being able to see each other’s data, card details passing through the app, exposed secret keys, unverified payment messages and missing backups. Each can be checked before launch.
Who is responsible for security in an app built with Lovable or a similar tool?
You are. Lovable disputed CVE-2025-48757 on the basis that “each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application”, and UK GDPR places the duty to secure personal data on the business that controls it.
Do I need to be PCI compliant if I use Stripe?
Anyone involved with processing, transmitting or storing card data must comply with PCI DSS. Stripe says its low risk integrations send payment information directly to Stripe without it passing through your servers, which reduces your obligations, and for Elements and Checkout it helps you complete your PCI validation form in its dashboard.
What is row level security in Supabase?
Row level security is a database setting that limits each user to the rows of data they are allowed to see. Without it, Wiz explains, the public key of a Supabase database, a service popular with AI-built apps, “grants full database access to anyone who has it”. It was missing in both the Lovable apps found in 2025 and the Moltbook database exposed in 2026.
Do I have to report a data breach from my app?
If the breach is likely to put people’s rights at risk, yes. The ICO says you must report it within 72 hours of becoming aware of it, where feasible, and tell the people affected if the risk to them is high.
Flux Dynamics is a fractional CTO who builds. If your app was built quickly and you want it checked before it takes money, tell us what you run and we will go through it with you.