Vibe coding security.
The 2026 breach checklist.
AI-built apps are shipping faster than anyone can review them, and they are leaking secrets at scale. This is vibe coding security in plain terms: why these apps expose API keys, the checklist that stops it, and the honest reason owning real code helps. Ownership is not safe by default. It is the difference between an app you can audit and a black box you have to trust.
The short answer
Vibe coding security, in one paragraph.
Most vibe coding security problems are not exotic. They are the same two mistakes, repeated at the speed of a prompt: a secret key pasted into the client where anyone can read it, and a server that trusts whatever the app sends instead of checking it. Both are easy to make when an AI hands you something that works on the first try and you ship it.
The fix is four habits: never put secret keys in client code, enforce access on the server, scope and rotate your keys, and if you use Supabase as your backend, turn on Row-Level Security. None of that is specific to AI. What AI changes is the volume. The rest of this guide is the evidence, the full checklist, and the honest version of where owning your code helps.
The evidence
Why vibe-coded apps leak secrets.
The pattern is documented, not anecdotal. A few numbers from 2025 and 2026 show how common exposed API keys and missing server checks have become as AI generated code security falls behind the pace of shipping.
of 20,000+ vibe-coded launches leaked Supabase keys in their frontend (SupaExplorer, Jan 2026)
API tokens exposed by Moltbook through a Supabase database missing Row-Level Security (Wiz, Feb 2026)
new hardcoded secrets in public GitHub commits in 2025, up 34% (GitGuardian, 2026)
of AI-generated code samples contained vulnerabilities, across 100+ models (Veracode, 2025)
Keys are landing in frontend code
A January 2026 SupaExplorer scan of more than 20,000 indie vibe-coded launch URLs found about 11% exposed Supabase credentials directly in their frontend code. The key was sitting in the app bundle, readable by anyone who looked. The dangerous version is the service-role key, which bypasses normal access rules entirely.
One missing rule exposed 1.5 million tokens
In February 2026, Wiz found that Moltbook, a vibe-coded AI social network, exposed roughly 1.5 million API tokens through a misconfigured Supabase database missing Row-Level Security. Row-Level Security is the rule layer that decides which rows each user may read or write. With it off, the database answered requests it should have refused.
Secret sprawl is accelerating
GitGuardian’s State of Secrets Sprawl 2026 report detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% year-over-year increase. And Veracode’s 2025 GenAI Code Security Report found 45% of AI-generated code samples contained security vulnerabilities across more than 100 large language models. The model writes code that runs. Whether it is safe is still on you.
None of this means AI writes uniquely bad code. It means a fast prompt-to-launch loop repeats the same vibe coding vulnerabilities at a scale no manual review was sized for. For the security fundamentals underneath all of this, Newly’s app security basics guide is the place to start.
The checklist
The vibe coding security checklist.
Most of a secure AI built app comes down to two ideas: secrets stay on the server, and the server decides what the client is allowed to do. Here is the do-and-don’t version you can run through before you launch.
Do this
- Keep secret keys server-side, ship only public scoped keys to the device
- Enforce every access rule on the server, never on the client
- Scope each key to the least it needs, then rotate anything that leaked
- If you use Supabase as the backend, turn on Row-Level Security and test it
- Read the generated code before launch, or have a developer audit it
- Add a secret scanner to your repo so a stray key fails the build, not production
Never do this
- Paste a service-role or admin key into the app so a feature works faster
- Assume a request is safe just because it came from your own app
- Ship a Supabase database with Row-Level Security still switched off
- Reuse one all-powerful key everywhere instead of scoped, rotatable ones
- Treat AI-generated code as reviewed simply because it runs
- Log secrets, or paste them into a chat or a screenshot
The one rule under every other rule
A public, scoped key in the client is fine by design. A secret admin key in the client is a breach waiting to be found. If you remember nothing else about vibe coding security, remember which kind of key you just shipped, and make sure the server, not the app, decides who gets to read what. Picking the right backend is part of this, so it is worth reading how to choose a backend before you commit.
The honest angle
What changes when you own the code.
Owning your app’s real code does not make it secure. It makes it auditable, which is a different and more honest claim. Here is what that actually buys you, and where it stops.
You can read exactly what the app does
A closed no-code platform hands you a running app and asks you to trust it. You cannot open the generated code, so you cannot tell whether a key is hardcoded or whether an access check exists. With Newly the output is standard React Native code in your project. You can search it for keys, read how each screen talks to the backend, and hand it to a developer for a real audit. That visibility is the honest advantage, not a promise that nothing can go wrong.
Access is enforced on the server, not the client
Most of the leaks in this article trace back to one mistake: trusting the client to decide what it is allowed to do. Newly's default bundled backend handles auth and data access on the server, so a request still has to pass the server's rules no matter what the app sends. That is the pattern that would have stopped the Moltbook leak, where a database answered requests it should have refused.
Per-row rules are one click away when you need them
Newly's bundled backend is Postgres-based and REST, and it enforces access on the server. If your app needs database-style rules on individual rows, where each user can read only their own records, Supabase is a one-click alternative backend and adds Row-Level Security for exactly that. Pick the backend that matches what your app has to protect, and turn the rules on before you launch.
Ownership is auditability, not immunity
Here is the part most marketing copy skips. Owning your code does not make the app safe by default, because whoever ships it is also the one who can leak a key. What you get is the ability to find and fix problems, not a guarantee you will never create one. Used with the checklist above, that ability is worth a lot. Sold as automatic safety, it would be a lie.
Where Newly fits
Newly gives you code you can audit.
Newly is a paid AI mobile-app builder, from $25 a month. You describe the app in plain language and it generates a real React Native and Expo codebase you own. For vibe coding security that ownership matters, because you (or a developer) can read exactly what the app does and harden it, rather than trusting a black box you cannot inspect.
Newly’s default bundled backend handles auth and data access on the server rather than trusting the client, which is the pattern that stops the most common leaks. If your app needs per-row rules, Supabase is a one-click alternative backend and adds Row-Level Security. None of this makes security automatic. You still run the checklist. Newly just makes sure you can.
FAQ
Vibe coding security, answered.
Vibe coding security is the practice of keeping an app safe when most of its code was generated by AI from plain-language prompts. It matters now because the volume is huge and the same mistakes repeat. A January 2026 SupaExplorer scan of 20,000+ indie vibe-coded launch URLs found about 11% exposed Supabase credentials right in their frontend code, and GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% jump over the year before. The risk is not that AI writes uniquely bad code. It is that a fast prompt-to-launch loop ships the same leaked-key and missing-server-check patterns over and over, at a scale no manual review was sized for.
Build on code you can actually audit.
From $25 a month, Newly generates a real React Native app you own, with a backend that enforces access on the server. It will not make security automatic. It will give you code you can read, harden, and trust.