Vibe coding security: checklist for Lovable, Bolt or Cursor apps
What to check before an AI-built app takes real customer or staff data: access rules, exposed keys, Supabase RLS, prompt injection, backups, Arabic, and when to rebuild.
Before an app built with Lovable, Bolt, Replit or Cursor takes real customer or staff data, test it the way an outsider would. Using test accounts on your own app, sign in as two different users, open the browser's developer tools and try to read the other person's records. That one test covers the centre of vibe coding security: who can see and change what. The AI tool wrote code that works in the demo, but only you know who should see which records, and only testing shows the code enforces it. Use the checklist below, fix access control first, and decide early whether the code is worth fixing.
Two illustrative cases: a private clinic group in Amman builds a booking app in Lovable on Supabase so patients can book visits and see lab results. In Dubai, an operations lead at a logistics company builds an internal tool in Cursor that sends driver incident reports to an AI model for summaries and stores staff leave records. Both could cause real harm if one user could read another's data.
The checklist in one view:
- Access: every request checks the user's role on the server.
- Secrets: no secret database key, payment key or AI provider key in code the browser downloads.
- Database rules: Row Level Security on for every exposed table, with policies tested per role.
- Inputs and AI: validation on the server, and model output treated as untrusted.
- Operations: dependencies audited, security events logged, one backup test-restored.
- Arabic: right-to-left layout, mixed text and Arabic search work.
1. Who can sign in, and what can each role see?
We recommend starting here because one access mistake can expose every user's records at once. Broken Access Control is A01, first in the OWASP Top 10:2025, and Authentication Failures is A07. An AI builder can produce a working login in minutes and still leave authorisation thin: the rule that says which records each signed-in user may read or change.
- For every action, confirm the server or database refuses it when the user lacks the role. A hidden button does not stop a request.
- Change a record ID in the address bar or in a request and confirm you get an error, not another patient's booking.
- Open every admin page twice: logged out, and logged in as an ordinary user.
- Password reset, email change and invitation links expire and work only once.
- For a staff-only tool, confirm a stranger cannot create an account, for example by turning off public sign-up or limiting it to the company's email domain.
In the clinic example, a patient sees only their own results, and reception sees the day's bookings but not lab results. If the app holds health, financial or staff records, data protection and sector rules can apply as well; which ones depends on the country, the sector and, in the UAE, whether you operate in a free zone with its own law such as DIFC or ADGM. This is general information, not legal advice; obligations depend on your sector and the data you hold.
2. Are any secrets in the code your users download?
Everything in the front end reaches the user's browser, and anyone can read it with the developer tools. If your project uses Vite (check package.json), the Vite documentation on environment variables says variables prefixed VITE_ are exposed in client-side code after bundling and should not contain API keys. The same applies to any key an AI assistant pasted straight into a component.
- Search the built files and the browser's Network tab for AI provider keys, payment keys, email service keys and the Supabase secret (service_role) key.
- The Supabase publishable (anon) key is meant for the browser. It is only as safe as your RLS policies, covered next.
- Move every other key into a server-side function, rotate any key that has ever been in the browser or the repository's history, and confirm .env files are not committed.
3. Do your Supabase RLS policies match who should see each row?
When the browser talks to Supabase directly, Row Level Security is your authorisation layer. The Supabase guide to Row Level Security warns that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and tells you to enable RLS on every such table. Once RLS is on, the publishable key returns no data until you add policies. Lovable's documentation says it can use your own Supabase project as the backend, and that its built-in backend, Lovable Cloud, is built on Supabase's open-source foundation, so this applies to Lovable apps on either.
- List every table in the exposed schemas and confirm RLS is enabled on each one.
- Read each policy back as a plain sentence ("a patient reads rows where patient_id is their user ID"). If you cannot, rewrite it.
- Look for policies whose condition is always true. Supabase notes that one for anonymous users lets every visitor read every row: keep it for public data such as a branch list.
- Check insert and update policies as well as read policies. A user who may edit their own profile must not be able to change its owner or role column.
- Check file storage too: uploaded lab reports or ID copies need the same per-user rules as tables.
- Test with two accounts per role, plus logged out, using only the publishable key. Keep the secret key, which bypasses RLS, on the server.
4. Is every input checked on the server, including what reaches the AI model?
Browser checks help honest users; the server must repeat them. Validate type, length and format for every field, limit uploads by type and size, and clean rich text before showing it to another user. Rate-limit sign-in, sign-up and any form that sends email or calls an AI model.
If the app calls an LLM
The OWASP Top 10 for LLM Applications 2025 lists Prompt Injection as LLM01. In the Dubai example, a driver's report could contain text written to steer the model. You cannot filter every such message, so limit what a manipulated model can do.
- Call the model from the server, never from the browser.
- Keep secrets and internal rules out of the system prompt; OWASP lists System Prompt Leakage as LLM07.
- Treat model output as untrusted: escape it before display and never run it as code or a database query (LLM05, Improper Output Handling).
- Give the model only the data and tools the current user may see. If it can send email or change records, require a person to confirm (LLM06, Excessive Agency). See our AI agent governance guardrails.
- Set per-user request limits and a spending limit with your AI provider where one is offered (LLM10, Unbounded Consumption).
- Test with hostile inputs in Arabic, English and mixed text. Our Arabic LLM evaluation guide covers building a test set in the dialects your users write in.
5. Dependencies, logs, backups and Arabic: the operational side of vibe coding security
Dependencies
Run your package manager's audit, remove unused packages, and confirm each package an AI assistant added has the exact name you meant. OWASP lists Software Supply Chain Failures as A03:2025. The Lovable security documentation says its Quick scan (database access rules, dependencies and MCP server exposure) runs on every publish; the Deep scan of application code runs when you start it, or on a schedule in Enterprise workspaces. Lovable states these tools do not replace a thorough security review.
Logging
Log sign-ins, failed sign-ins, role changes, data exports and admin actions, and send alerts to a named person. Keep passwords, tokens and full health records out of the logs. OWASP lists Security Logging and Alerting Failures as A09:2025.
Backups
Supabase's backup documentation says Pro, Team and Enterprise projects are backed up daily, and advises Free plan projects to export their data regularly. Restore one backup into a test project before launch and time it.
Arabic and right-to-left basics
- Arabic pages set lang="ar" and dir="rtl", and arrows and progress steps are mirrored.
- Mixed text such as an English product name, a phone number or a booking reference inside an Arabic sentence displays in the right order.
- Arabic search finds words with or without hamza, and with ta marbuta or ha.
- Emails, PDFs and error messages render Arabic correctly, and no error message reveals system internals.
Fix, refactor or rebuild: how to decide
We recommend making this call after the access and secrets checks, because those findings show a lot about how the code was put together. A rebuild costs more time up front, but patching a weak data model can open new gaps as further AI-generated changes land.
| What you find | Decision | Illustrative example |
|---|---|---|
| Isolated gaps: RLS off on a few tables, one exposed key, no rate limits. The data model fits the business. | Fix in place | The Amman clinic app enables RLS and moves one key to the server. |
| Access checks scattered across many screens, the same logic copied, no tests, but a sound data model. | Refactor | The Dubai tool moves access rules into server functions and database policies. |
| The data model does not fit the business, sign-in was added late, secrets sit throughout the history and nobody can explain the code. | Rebuild | A multi-branch retailer's app has no notion of a branch, so it is rebuilt. |
Whichever you choose, add automated tests for the access rules, so the next AI-generated change cannot quietly undo them.
How to start your vibe coding security review
Start your vibe coding security review with the two-account test this week, then the rest of the checklist in order. If you want a second review, our AI-Built App Production Review audits apps built with Lovable, Bolt, Replit or Cursor, then fixes, refactors or rebuilds them with test automation. See the AI-built app page and the Transformation Lab. If you are unsure where to begin, the free AI Exposure Scan is a 45-minute conversation that ends in a written next step.
Frequently asked questions
Is vibe coding safe for production apps?
It can be, once the code has been checked like any other code before real data goes in. AI builders produce working features quickly, but they cannot know who should see which records unless you tell them, and they do not prove the rules hold. Before launch, test access with two accounts per role, remove secret keys from the browser code, enable and test Supabase Row Level Security, validate inputs on the server and confirm you can restore a backup.
Is the Supabase anon key safe to put in the frontend?
The publishable (anon) key is meant for the browser, but it is only as safe as your Row Level Security policies. Supabase's documentation says a table in an exposed schema without RLS can be read and written by any role with a grant on it. Enable RLS on every exposed table, test each policy, and keep the secret (service_role) key, which bypasses RLS, on the server only.
Does Lovable's security scan replace a security review?
No. Lovable's documentation says its Quick scan runs automatically when you publish and covers database review and a dependency audit, while the Deep scan of application code runs when you start it, or on a schedule in Enterprise workspaces. Lovable itself states the tools do not replace a thorough security review, and suggests an additional professional review for apps handling sensitive data or critical functions.
When should an AI-built app be rebuilt instead of fixed?
Rebuild when the data model does not fit the business, sign-in was added late, secrets appear throughout the code history and nobody can explain how the code works. If the data model is sound and the gaps are isolated, fix in place. If access checks are scattered and untested but the data model holds, refactor first. In every case, add automated tests for the access rules.
Get new insights by email
One email when we publish something useful. No spam; leave any time.
Services in this article
Related lab: Transformation Lab ↗
