AIGDPRPrototypeSaaSMaintenance
Security checklist for a vibe-coded app before launch
9 min read
Before you open a vibe-coded app to customers (built with Lovable, Bolt, Base44, Cursor or anything similar), check four things ahead of everything else: one user can never see another user's data, no secret key is visible in the browser, private pages reject signed-out visitors, and a backup can be restored. The first three fall under the number one risk in the OWASP Top 10 2025: broken access control.
Most vibe coding security checklists are written for developers. This one is written for the founder. It separates what you can verify yourself in an afternoon from what needs someone who reads code.
Why generated apps fail in particular ways
AI writes code that works: screens render, buttons respond. Security is about what happens when someone uses the app in a way you did not plan for. A builder optimises for the first, not the second.
Three patterns come up again and again:
- Checks that live only on screen. The "Delete" button is hidden from non-admins, but the database accepts the delete if someone calls it directly.
- Missing access rules in the database. Supabase's documentation, the database behind several of these tools, warns that a table in an exposed schema without row-level security (RLS) is readable and writable by any role with a grant. That mechanism is at the heart of CVE-2025-48757, published in May 2025 about apps generated with Lovable, which the vendor disputes.
- Secrets in the wrong place. An API key pasted into a chat can end up in the code sent to the browser, where anyone can read it.
The vendors are upfront about this. Lovable's security documentation states that the app owner is responsible for security appropriate to the use case, and that its scanning tools cannot guarantee complete security.
What you can check yourself
None of these checks require reading code. Block out an afternoon and keep a simple sheet with the result of each one.
1. The two-account test
Create two customer accounts, A and B, each with a little data (an order, a file, a message). Signed in as A:
- find an identifier in the address bar (a number, a string of letters) and swap it for the identifier of one of B's records;
- try to open, edit, then delete that record.
If any of those actions succeeds, do not launch. It is the most common flaw, and the most serious one.
2. The signed-out visit
Open a private browser window, do not sign in, and paste the address of a private page (dashboard, admin, invoice). You should be sent to the sign-in page without seeing any content, not even for a second.
3. Roles
If the app has admins, sign in with an ordinary account and try the admin page addresses directly. Hiding a link is not enough; the address itself must be refused.
4. The code repository
If your code syncs to GitHub, make sure the repository is private. For public repositories, GitHub scans the full history for free looking for leaked credentials. If an alert appears, rotate the key with the provider concerned. Deleting it from the code is not enough, because it stays in the history.
5. Admin accounts
Turn on two-factor authentication everywhere the app keeps its keys: the AI builder, GitHub, the database, the payment provider, the domain registrar, email. An attacker who takes over one of these accounts does not need a flaw in your code.
6. Restores
Ask where the backups live, then have one restored to a test environment. A backup that has never been restored is an assumption.
7. Visible obligations
Terms, a privacy notice, cookie information. If you serve customers in the EU or the UK, GDPR applies whatever tool built the app; our GDPR checklist for a business application covers what the design needs to include.
What needs a developer
The following items require reading code or configuration. They follow the order of the OWASP Top 10 2025.
| OWASP 2025 risk | What the developer checks |
|---|---|
| A01 Broken Access Control | RLS on every table, server-side permission check on every action |
| A02 Security Misconfiguration | Service keys out of the browser, security headers, debug modes off |
| A03 Software Supply Chain Failures | Unused dependencies removed, versions current, vulnerability alerts on |
| A05 Injection | Server-side input validation, parameterised queries |
| A07 Authentication Failures | Rate limits on sign-in, safe password reset |
| A09 Security Logging and Alerting Failures | Errors and sensitive actions logged, alerts on anomalies |
| A10 Mishandling of Exceptional Conditions | Safe behaviour when a third-party service is down |
Two areas deserve extra attention in a generated app:
- Payments. Confirmation that a customer has paid must come from the payment provider, verified on the server, never from the page the customer sees. Otherwise a subscription can activate without a payment.
- AI-written server functions. They often run with elevated privileges. Each one must check who is calling before it acts.
To go further, OWASP ASVS (version 5.0.0, published on 30 May 2025) lists requirements you can verify one by one. The UK National Cyber Security Centre keeps a free collection of guidance for developers, and OWASP's secrets management cheat sheet explains how keys should be stored and rotated.
Three cases that call for more caution
Some apps go beyond this checklist, either because mistakes cost more or because the risk takes a different shape.
- AI features inside the app. If customers chat with an assistant, or the app summarises documents they upload, malicious text can steer the model away from its instructions. Prompt injection is the first entry in the OWASP Top 10 for LLM Applications (2025 edition), followed by sensitive information disclosure. A simple rule: the assistant must never hold more permissions than the user talking to it.
- Files uploaded by users. Attachments, photos, receipts: each file must be stored so that only its owner can read it, and its type must be checked on the server.
- Sensitive data. Health records, payment details, information about children: regulation adds its own requirements, and a review by a security professional before launch stops being optional. Specialist legal advice is worth getting too.
In all three cases, the checklist is still the starting point, but it is not enough on its own.
Automated scanners: useful, not sufficient
Lovable offers a quick scan that runs automatically at publish time and a deeper code scan, according to its documentation. Other platforms have their own checks, and independent tools scan dependencies. Run them all; they catch obvious mistakes fast.
What they cannot know is what your business allows. No scanner can guess that a branch manager should only see their own branch's records, or that a finalised invoice can no longer be edited. Those rules get tested with real accounts and scenarios written by someone who understands the business.
The order of play before launch
- Run the seven checks in the first section and write down each result.
- Fix access first. A failed two-account test blocks the launch; everything else can be scheduled.
- Get the code reviewed on the points in the second section: at least access rules, secrets and payments. Our business application security essentials lists the questions to ask whoever does it.
- Separate test and production before any further changes by chat.
- Open gradually, to a few trusted customers first.
Who should do that review? Ideally someone who did not write the code, human or AI, and who knows the stack the builder generated. Ask for a written report that lists each finding, its severity and how it was verified, then rerun the two-account test yourself once the fixes are in. A review you cannot check is just another assumption.
If the review shows some modules need hardening or rewriting, our guide to taking a Lovable, Bolt or Base44 app to production offers a module-by-module grid. And if you are still choosing a tool, Lovable vs Bolt vs Base44 compares their back ends and export options. Where your data is hosted also matters for European customers; see hosting a business application in Europe.
How we work
LPR Studio writes code with AI too. Every change goes through automated tests, a review and human sign-off before it reaches production. If you have a generated app to open to customers, bring it along: we present a free prototype of the hardened version over video within 5 business days, with the items on this checklist that still need work.