Two mistakes cause most vibe-coded apps to get hacked or leaked: a hardcoded secret committed to a public repository, and broken authorization that lets anyone swap an ID in the URL and pull up someone else's data. Neither one requires a security background to check. Both can be tested in under five minutes, before you write a single line of a fix.
What a hardcoded secret actually is
A secret is any string that proves who you are to another service: an API key for OpenAI or Stripe, a database password, a signing token for your login provider. 'Hardcoded' means that string got typed or pasted directly into your source code instead of being kept in a separate, private configuration file. When an AI coding tool wires up a working integration, it often writes the key straight into the file it just created, because that is the fastest way to make the demo run.
The key works. It also now lives in plain text, inside a file that gets pushed to your repository the next time you save. If that repository is public, which is the default on some free hosting and AI builder platforms unless you change it, the key is visible to anyone who looks, including automated bots that scan GitHub for exactly this pattern within minutes of a push.
The scale of the problem
This is not a rare slip. GitGuardian's State of Secrets Sprawl 2026 report found roughly 29 million new hardcoded secrets exposed on public GitHub in 2025, a 34% jump from the year before and the largest single-year increase the company has recorded. Secrets tied to AI services specifically, keys for model providers and AI coding assistants, grew 81% year over year, faster than the overall trend. Vibe coding did not invent this problem, but it moves fast enough to make it worse: tools built to ship quickly rarely stop to ask where a key should live.
What broken authorization actually means
Authorization is the check that confirms you are allowed to see a specific piece of data, not just that you are logged in at all. A vibe-coded app can correctly verify that you are a real, logged-in user (authentication) while never checking whether the invoice, profile, or order you are requesting actually belongs to you (authorization). The bug shows up as a URL or API request that carries an ID, something like an order number or account number, and the app trusts that number without checking who it belongs to.
Change the number 4471 to 4472 in your browser's address bar while logged into your own test account. If someone else's invoice, profile, or booking loads instead of an error message, the app has broken authorization. Security researchers call this broken object-level authorization, or BOLA; it is closely related to what used to be called an insecure direct object reference, or IDOR.
Escape.tech scanned roughly 1,400 vibe-coded applications running in production and found 2,038 critical vulnerabilities and more than 400 exposed secrets, along with 175 confirmed instances of exposed personal data. Broken object-level authorization is a well-documented, frequent finding in scans like this one: someone changes an ID in a URL and pulls up another person's account, invoice, or record. The pattern is common because AI-generated database code tends to filter queries by the ID supplied in the request, without checking whether the person making the request actually owns that record.
Gut check: if your app has a URL that looks like /orders/4471, or an API call that takes a plain numeric ID, that endpoint is worth testing before anyone else finds it first.
Why vibe coding makes this pattern more common, not just more visible
AI coding tools generate a full, working stack in minutes: a frontend, a backend, a database, and often a login system, all wired together from one prompt. That speed is the entire appeal, and it is also why security gets skipped. A developer setting up authentication by hand tends to confront the ownership-check question directly, because writing it out forces the decision. A model asked to let logged-in users view their orders will often write a query that fetches an order by ID and leave out the line confirming the order belongs to the requester, because the visible feature still works without it. Nobody tested with a second account, so nobody noticed.
The same shortcut shows up with secrets. Ask an AI tool to connect an app to Stripe, and the fastest path to a working checkout page is pasting the secret key directly into the function that calls Stripe's API. It runs. It also means that key now sits in a file headed for your repository, and unless you specifically ask for a safer pattern, most tools will not volunteer one on their own.
Common places secrets hide in a vibe-coded project
- Payment provider keys: a Stripe or PayPal secret key pasted directly into a checkout or webhook function.
- AI provider keys: an OpenAI, Anthropic, or other model API key typed straight into a fetch call or client setup.
- Database connection strings: a full connection URL with the username and password baked into the string itself.
- Authentication provider secrets: an OAuth client secret or session-signing key pasted into a login or redirect handler.
- Admin credentials: a hardcoded username and password for a dashboard or debug panel meant to be temporary.
What an environment variable actually does
An environment variable is a value your hosting platform stores separately from your code and hands to the running app at startup, instead of a value typed into a file that gets versioned and shared. In practice, the key lives in a settings panel on your host, whether that is Vercel, Netlify, Replit, or Render, not in a file that anyone with repository access, or anyone who finds the repository public, can read. Moving a key into an environment variable does not make your app harder to run; it changes where the value is stored, not how the code uses it.
A checklist you can run today, no coding required
- 1. Search your own repository for secrets before you make it public. Look for the text 'API_KEY', 'SECRET', 'PASSWORD', 'sk-', and 'Bearer' inside your project files. Most code hosts, including GitHub and GitLab, also offer a free built-in secret scanner you can turn on in repository settings.
- 2. Check whether your repository is actually private. Free tiers on some AI builder and hosting platforms default new projects to public. Open the project's settings page and confirm visibility is set to private; do not rely on a label on the dashboard.
- 3. Test ID-swapping on your own app. Log in as one test account and note a URL containing a number, such as an order, profile, or document ID. Log in as a second test account and manually change that number in the address bar. If someone else's data loads, that is a broken authorization bug.
- 4. Move every key and password into environment variables. Ask your AI tool directly to move all API keys and secrets out of the code and into environment variables, then confirm none remain hardcoded by checking the files yourself instead of trusting the tool's word for it.
- 5. Never commit a .env file. Add .env to your .gitignore file before your first commit, not after. If you already committed one, treat every key inside it as burned: rotate all of them rather than just deleting the file.
- 6. Rotate any key that was ever exposed, even briefly. Removing a secret from your latest commit does not remove it from your repository's history; anyone can still find it by browsing old commits. The only real fix is generating a new key and revoking the old one at the provider.
Why asking the AI to fix it is not enough on its own
Asking a coding assistant to patch a vulnerability after the fact helps, but it does not replace verification. AI tools optimize for a working feature, not for confirming a fix actually closes the gap, and a patch that silences an error message can still leave the underlying check missing. Treat every 'fixed' response as a claim to test, not a guarantee: repeat the ID-swap test and the secret search after any fix, the same way you ran them the first time.
| Risk | How It Shows Up | 5-Minute Check |
|---|---|---|
| Hardcoded API key | A working feature that pastes a key straight into a source file | Search your repo for 'API_KEY', 'sk-', 'SECRET'; confirm the repo isn't public |
| Committed .env file | Your local config file gets pushed to the repo on the first commit | Look for a .env file in your repository's file list on GitHub or GitLab |
| Broken object-level authorization | A URL or API call with a plain numeric ID that isn't checked against who's asking | Log in as two test accounts, swap the ID in the URL, see whose data loads |
| Public repo by default | Free tiers on some builder platforms create new projects as public unless changed | Open project settings and confirm visibility is set to private |
| Secret left in git history | Deleting a key from the latest commit does not remove it from earlier commits | Search the repository's commit history, not just current files, for old keys |
What to do if you already leaked something
If a search turns up an exposed key, the fix is rotation, not deletion. Log into the provider, whether that is OpenAI, Stripe, your database host, or whichever service issued the key, generate a new one, and revoke the old key immediately. A revoked key stops working everywhere, including in any script that might already be using it without your knowledge. Only after the old key is dead should you clean up the code and, if needed, scrub the repository history. Check the provider's usage logs for the days the key was exposed; unexpected charges or requests are the clearest sign someone else already found it.
Building the habit so this does not happen again
A one-time scan catches what is already wrong. Staying clean going forward is a habit, not a single fix. Turn on your host's automated secret scanning, GitHub's is free and enabled per-repository in settings, so a new leak gets flagged the moment it is pushed instead of months later when a stranger finds it first. Get in the habit of asking, before every 'make this public' or 'deploy this' click, two questions: does anything in this project reveal who I am to a paid service, and does every URL that includes an ID also check who is asking for it. Those two questions cover most of what actually goes wrong in scans of real vibe-coded apps.
What this checklist does not cover
Hardcoded secrets and broken authorization are the two failures most likely to burn a vibe-coded app, and they are also the two a non-technical builder can verify without any security background. They are not the only things worth a look once those are clean. Rate limiting, nothing stopping someone from hammering a signup or login endpoint thousands of times a minute, input validation, a form field that accepts far more than it should and passes it straight to a database, and outdated dependencies, a library the project relies on with a known, published vulnerability, all deserve a pass afterward. None of them tends to be as immediately damaging as a public secret or a swapped ID, which is why they come second, not first.
The same discipline applies to AI chat memory, not just code. Pasting a live API key, a customer's personal data, or a database password into a chatbot so it 'remembers' creates a copy of that secret outside your control, and most AI chat memory features were not built to treat it as sensitive. MemX (memx.app) keeps your own project notes, decisions, and context private by architecture, separate from any single vendor's training pipeline, but that is a note-taking safeguard, not a substitute for the secret hygiene in this checklist. Rotate what leaked, and keep keys out of chat logs the same way you keep them out of code.
01How do I check if my Replit or Lovable app has exposed API keys?
Search your project files for the text 'API_KEY', 'SECRET', or 'sk-', and check whether your repository or project is set to public. Most hosting platforms also offer a free automated secret scanner in repository settings; turn it on before you ship.
02What is broken object-level authorization in plain English?
It means the app checks that you're logged in, but not that you own the specific record you're requesting. Change a number in the URL, like an order or profile ID, and if someone else's data loads, that check is missing.
03Can I just ask my AI coding tool to fix security bugs?
You can ask, but verify afterward. AI tools tend to patch the visible symptom without confirming the underlying check exists. Re-run your own test, such as the ID-swap check, after every fix instead of trusting the tool's confirmation.
04Do I need to know how to code to check for these issues?
No. Searching your files for the word 'SECRET' and swapping a number in a URL while logged in as two different test accounts both take a few minutes and no programming knowledge.
05What should I check first before making my vibe-coded app public?
Two things: search your repository for hardcoded keys and passwords, and confirm your repo's visibility is private. Those two checks catch the failures that show up most often in scans of real vibe-coded apps.
