Vibe Coding Security: What to Check When AI Builds Your App

Vibe coding security comes down to 3 questions you can ask without reading code: what can a visitor's browser see on your public pages, where do your secret keys live, and can one signed-in person read another person's data? You can check the first 2 yourself in about 30 minutes. For anything that holds sensitive data, bring in a real security reviewer.

AI builders are good at making an app that works. Working is not the same as safe. Here is a plain-English tour.

What does security mean when AI writes the code?

Security means the right people can do the right things with the right data, and nobody else can. For a small app, that boils down to 3 jobs: keep secrets secret, keep each person's data private, and make sure only real owners can change things.

An AI builder will happily make a login screen that looks right. Whether the rules behind it hold is a separate question, and the tool can't always tell you. Lovable's security documentation says its scans help find common problems but cannot guarantee complete security, and that you are responsible for meeting the security needs of your app, especially if it handles sensitive data (no date shown, read 6 October 2026).

What can a visitor see on your public pages?

Everything your app sends to a visitor's browser is, by definition, visible to that visitor. That includes the words and images, and also the code the browser downloads to run your page. A secret placed in that code is not secret.

Hypothetical example: a made-up recipe-sharing app has a public home page, a page of featured recipes, and a sign-up form. This table is the spine of the guide: for each thing, what a visitor should meet, which part of a public-pages report speaks to it, and who can really confirm it.

The top 2 rows are things a customer can see, so a public review can speak to them. A public-pages report cannot speak to the bottom 3, so someone with access has to check them. If you want the full 2-account method for the private-recipes row, our guide to testing a vibe-coded app without being a developer walks through it.

What is an API key, and where do secrets leak?

An API key is a long password that a service gives your app so it can use that service: send email, take payments, or call an AI model. Whoever holds the key can act as your app, so we treat one like a house key: it lives somewhere safe, not under the doormat.

The classic leak is that the key sits in the app's code and the code reaches the visitor's browser. Replit's secrets documentation names 3 other ways a hard-coded key gets out: sharing a public project or copy-pasting code, checking code into a public repository, and showing your code on a live stream or screen share (no date shown, read 6 October 2026). Our own advice, not Replit's: a chat with an AI is one more place a key can end up, so keep real keys out of it too.

The fix is the same everywhere. Keep keys in a secrets store, and make the calls that need them from the server side, not from the browser, as Lovable's security documentation says (no date shown, read 6 October 2026).

• We would never paste a real key into a chat prompt. Ask the AI where the key should go, then add it through the tool's secrets feature.
• If a key was ever visible in code or in a chat, treat it as spent. Replace it where it was issued, then update your app.

Some keys are meant to be public and some are not. Don't guess: ask your tool or the service whether a key is safe in the browser.

Who can read whose data?

If we could only check one thing once you have sign-ups, it would be this one. The rules that decide who can read or change which stored records are called database rules. In Lovable's setup they are row-level security, or RLS: rules that say which person may read or change each row of stored data.

OWASP's Top 10:2025 list of web app risks has a category called broken access control, which covers failures that let users act outside their intended permissions. Its page gives relying on checks that run only in the browser as one example (OWASP, Broken Access Control, 2025 edition, read 6 October 2026). Lovable's Quick scan flags tables with no per-record rules and rules that let everyone through (no date shown, read 6 October 2026).

If your tool doesn't run a check like that, ask the AI plainly: "For each table, who can read it and who can change it? Show me in plain English." Here is what we would hope to hear back: "A member can read and edit only their own recipes. Anyone can read recipes marked public." Something vague, like "the app is secure," deserves another round of questions.

Is sign-in set up the safe way?

Sign-in is where a friendly screen can hide a lot, so here are 3 things we would check without opening any code:

• Passwords are never shown or emailed back. A reset email that contains your old password is a red flag.
• Private pages need a signed-in person. Open one in a private browser window while signed out. You should be sent to sign in.
• The server does the refusing, not the screen. A button hidden from regular users is not a lock. Our guide to design tips for a vibe-coded app makes the same point from the design side.

Ask the AI to use your tool's built-in sign-in, not its own password handling. If an answer is "I'm not sure," write it down for a reviewer.

What do your builder's own security scans do?

We would use them, with eyes open. Lovable describes a Quick scan that runs before you publish, covering database rules and known problems in the software your app depends on, plus a Deep scan you run on demand that looks further, including access control, secrets, and sign-in. It also says to resolve critical issues before making your app public (no date shown, read 6 October 2026).

Replit's Project Security Center describes the checks made while its Agent builds as an early, lightweight check, not a full codebase review, and says Auto-Protect covers dependency flaws only, so a separate Agent security scan is how you review your own code (no date shown, read 6 October 2026). A clean scan is a good sign, not a guarantee.

What can a public-pages review see, and what can't it?

Here is where we draw our own line: our audit is not a security review. It is an AI audit scored against a fixed rubric, and it reads what a customer sees at your link: public pages only, nothing behind a login. It clicks through those pages, reads the rendered page plus desktop and mobile screenshots, and runs an AI generator fingerprint check for the marks AI builders leave behind. The result is a score out of 100 with fixes ranked by what to do first.

That is useful for the visible side of trust, like contact details, a current footer year, and legal pages, and for what happens after sign-up. A public-pages report cannot speak to a key hidden in your code or to whether one member can read another member's records, so treat a good score as a good first impression and nothing more.

What is a 30-minute check you can do yourself?

1. Sign out and browse. Visit every private page of your own app in a private window. Nothing private should load.
2. Make 2 test accounts that you own, put something private in the first, and see whether the second can find it.
3. Ask the AI 3 plain questions about your own app. Where are my keys stored? Who can read each table? What stops a signed-in member from opening another member's page?
4. Search your own chat history. If you ever pasted a real key, replace it today.
5. Run your tool's scan, and fix every critical item before you publish.
6. Save the answers. A few lines in plain English become the brief for a reviewer.

Our vibe coding checklist covers the wider list, including roles and permissions.

When should you hire a real security reviewer?

Bring in a person whose job is security when your app holds payment details, health or financial information, children's data, other businesses' data, or anything that would hurt someone if it leaked. Do it before you take real customers, not after.

Bring your notes, your scan reports, and a list of every service your app connects to. A reviewer can read the code and settings that we, and any public-pages pass, can't. Be wary of anyone who promises your app is "100% secure." Nobody honestly can, and Lovable says as much about its own scans.

When the basics hold up, the next stop is launch day itself, and our website launch checklist covers that order of operations. Most of this is just asking your app the right questions, and you can do that.