Vibe coding security
Vibe coding security is the practice of finding and fixing the vulnerabilities that appear when software is built by prompting an AI rather than written line by line. The failures are not exotic. They are the same handful every time: a database left readable, a secret compiled into the browser bundle, storage left open, and no security headers anywhere. What changes is the speed — an app reaches production in an afternoon, and the configuration nobody chose goes with it.
ShipReady scans a deployed URL for 194 of these conditions and reports only what it can observe directly. Below is what goes wrong most often, what it looks like per tool, and how to check your own app.
01The database is readable by anyone
criticalThis is the one that matters most, and it is the one AI builders get wrong most often. Supabase gives your browser a public anon key — correctly, it is designed to be public — and the only thing standing between that key and your data is Row Level Security. RLS is off by default on new tables, and generated code very often never turns it on. The result is a table that answers unauthenticated reads from anyone who opens your page source. No exploit, no skill: just the key you already published and a URL.
02A secret shipped to the browser
criticalAI coding tools reach for an environment variable when they need a credential, and the prefix decides everything: NEXT_PUBLIC_ and VITE_mean “inline this into the client bundle”. A model that cannot tell a publishable key from a secret one puts both behind the same prefix, and the secret ends up in JavaScript that every visitor downloads. The tell is that nothing breaks — the app works perfectly, which is exactly why it ships.
03Firebase rules left in test mode
criticalFirebase starts locked, then asks you to open it up while you build. The rule that makes development frictionless — allow read, write: if true— makes the database world-readable, and there is no error, no warning and no deploy-time check to say so. Storage has its own separate rules that do not inherit from Firestore’s, so securing one does nothing for the other.
04The AI tool left its own files on your server
mediumThe files that configure your assistant — .cursorrules, MCP server definitions, agent config — are written into your project directory, and a build that copies the directory wholesale serves them at your domain. They routinely describe your internal architecture, and some of them hold credentials. This is the failure mode unique to building with AI: no human put these files there, so no human thinks to exclude them.
05No security headers at all
highHeaders are infrastructure, and generated apps are application code — so nothing emits them. Without a Content-Security-Policy, a single injected script runs with full access to the page and one XSS becomes account takeover. Missing HSTS leaves a downgrade attack open; missing frame protection leaves clickjacking open. Individually small, collectively the difference between a hardened deploy and a demo.
06Payments still in test mode
highA checkout wired with test keys works flawlessly in every way except taking money. Nothing errors, the success page renders, the order appears — and no payment is ever captured. It is the quietest failure on this list, and it is usually found by a founder wondering why launch week produced no revenue.
Security by AI coding tool
The same risks land differently depending on what built the app. Each guide covers the specific defaults of one tool, the risks that follow from them, and how to fix each.
Frequently asked questions
- What is vibe coding security?
- It is the practice of finding and fixing the vulnerabilities that appear when an application is built by prompting an AI rather than written line by line. The risks are not exotic — they are ordinary misconfigurations — but they arrive faster than review can catch them, and they cluster: an open database, a secret in the client bundle, permissive storage rules, and no security headers.
- Is code written by AI less secure than code written by hand?
- The generated code itself is usually unremarkable. What differs is what surrounds it: configuration nobody chose, defaults nobody reviewed, and files nobody knew were there. Almost every real failure in AI-built apps is a configuration or deployment problem rather than a flawed algorithm, which is why scanning the deployed result catches more than reading the source.
- How do I check whether my vibe-coded app is secure?
- Scan the deployed URL. ShipReady runs its full check suite against a live site and reports only what it can observe directly, with the evidence it observed and a fix prompt you can paste back into your editor. It needs no source access and no agent installed.
- Does ShipReady scan my source code?
- No. It scans your deployed application over the public internet, the same way a visitor or an attacker reaches it. That is a deliberate limit: it means findings are things genuinely exposed to the world rather than theoretical issues in code, and it means it works whatever tool built the app.
Check your AI-built app in about a minute
Paste your live URL. ShipReady reports every one of these conditions it can observe, with the evidence and a paste-ready fix. Free, no signup.