Vibe coding security: what shipped AI sites leak, and how to see it from outside.

Is vibe coding safe?

No, you can't assume your vibe coded site is safe: studies show AI-generated code regularly ships with exploitable flaws. Open your developer tools and read your response headers. Do you see any security headers? The Tenzai study looked at 15 applications built on Cursor, Claude Code, Replit, Devin and OpenAI Codex, and found that zero set any. Not one. (Yes, even the ones that looked polished in the browser.) Check yours.

Your model won't save you. IOActive found average security performance across all models was 59%, and no model gave you 100% secure output. And the newer ones aren't immune either. A December 2025 study from Carnegie Mellon, Columbia and Johns Hopkins found that when you prompt leading models, you get functionally correct code 61% of the time. Only 10% of what you get is both correct and secure. Georgia Tech's Vibe Security Radar tracked 35 new CVE entries caused directly by AI-generated code in March 2026, up from six in January. That's a curve, not a blip. Before your next deploy, check your commits. The fix is yours to make.

You own what you ship, and your tool doesn't make your site safe. Review your code, test your pages and fix what you find, and your site can hold up. But accept your code untouched, and nobody has checked it, you included. Your review is the only check your code gets. Run the free assessment on your URL. Read your headers, then fix those first.

What security mistakes do AI-built sites make most often?

Three problems turn up most often: secrets in your browser, databases left open by missing access rules, and missing security headers. Search your source and your bundles for sb_secret_ or service_role. Find either one, and you shipped your backend-only key to every visitor. Escape.tech studied 5,600 vibe-coded applications like yours and found over 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed PII. If you vibe coded, your bundle may hold the same. So check yours.

If you use Supabase, check yours. VibeAppScanner reports Supabase was the largest source of critical findings across the apps it scanned, almost always because Row Level Security was left off. Your tables need it on. Shipping a mobile app? Your rules face the same test: Barrack AI's table attributes a January 15, 2026 incident to Firebase rules reading 'allow read: if true', and a review of 196 iOS AI apps blamed Firebase misconfigurations in 98.9% of cases. Search your rules for that line (it is one line, and it is easy to miss). If it's there, fix it first.

Test your login and your limits. IOActive found authentication, rate limiting and cryptography failed across nearly all models. And every tool in the Tenzai study introduced Server-Side Request Forgery, a habit of the category, so check your app for it whichever tool you used.

What can a public read of your site reveal about its security?

Your public read shows what your site hands every visitor's browser: response headers, markup, scripts and which URLs answer. Open your homepage and check your Network tab, and you will see which of the headers OWASP lists your site sends. Does your Server or X-Powered-By header name your stack? That is a free hint for anyone probing your site, and you gave it away without asking for anything back.

You may also find a Supabase project URL and key in your JavaScript. That alone is not a failure of your build. Wiz states that it does not automatically signal a security failure; the danger lies in how the backend behind your key is configured. Ask what your key can reach. Stingrai notes that an exposed URL and key reach the auto-generated REST API, so check your own bundle for both. Your key is a doorbell. Your backend settings decide who gets in.

Your public read cannot show whether Row Level Security is on, what your policies say, who can log in to your site, what your analytics record, or how your server code handles input. Spot a key? Check your database settings. It is a prompt, not a verdict. And the assessment reads only your public pages and does not log in, so your private settings stay yours to check.

Which headers should an AI-built site send?

Your site should send Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, plus a framing control you pick. The three Cross-Origin policies are optional extras. Read your homepage response headers and check off every name you find. OWASP says proper response headers help prevent cross-site scripting, clickjacking and information disclosure on your pages. And every name you lack leaves a gap (a quiet one, since nothing breaks when a header is missing). Tenzai found zero of 15 AI-built applications set any, so if you built yours with AI, check it. Adding a header costs nothing. A missing one can cost you plenty.

Send your CSP as an HTTP header, not a meta tag. OWASP says a header covers every response and supports the full feature set, while a meta tag cannot give you framing protections, sandboxing or violation logging. Put frame-ancestors in your header: MDN says it gives you more options than X-Frame-Options. Still seeing X-Content-Security-Policy or X-WebKit-CSP in your responses? Drop both. They are deprecated, and they are doing nothing for you.

Set your X-Content-Type-Options to nosniff so your visitors' browsers honor the Content-Type you declared, as security testers expect from your site. Strict-Transport-Security needs a max-age in seconds. Want preload? You need at least one year and includeSubDomains, so check your current value first. But don't flip it casually on your domain (preload is hard to walk back). Before you change your header, read the requirements.

How do exposed keys, open endpoints and default configs show up?

You will see them as a database key in your JavaScript, REST paths on your site that answer without a login, and defaults you never changed. Check your key prefix. Your sb_publishable_ key is low privilege, so you can expose it with RLS on. Your sb_secret_ key is backend only and bypasses RLS. And your legacy anon and service_role keys map to those two.

Moltbook shows what you risk. Its Supabase key sat in client-side JavaScript with no RLS policies. Within three days of launch, Wiz found 1.5 million API authentication tokens, 35,000 email addresses and private messages exposed. Without RLS, that key gave anyone full database access, and yours would too. Your key may be visible as well, so your policies decide the damage. Search your bundle, then read your policies.

Your defaults matter too, so check yours. Supabase docs say tables you create in public on your existing projects receive SELECT, INSERT, UPDATE and DELETE privileges for anon, authenticated and service_role, and the platform default is changing. Search your policies for 'to anon using ( true )'. Find it, and every unauthenticated visitor can read your table. That is the whole exploit.

What should you fix first on a vibe coded site?

Fix your exposed backend secrets first, then your database access rules, then your headers, then the logic flaws that need your code review. Search your bundles for sb_secret_ and service_role. If either appears, rotate that key now: Stingrai advises it for an exposed service_role key. Keep your secret keys on the backend only. A leaked key stays leaked until you replace it, and deleting the line from your code does not replace it.

Second, enable RLS on every table in your exposed schema, as Supabase docs direct. Read each of your policies that say 'to anon using ( true )' and confirm you meant it to be public. Third, add the headers from the previous section. Headers limit damage rather than close a hole. So they come after your data.

Last, review your authentication, rate limiting, CSRF protection and Server-Side Request Forgery handling in your code. IOActive found that prompts like 'write secure code' were often ineffective or counterproductive. So read your code instead of re-prompting your tool.

How do you check your site's security pillar for free?

Enter your site's address into the free assessment, and you get your score out of 100 in about two minutes, with your evidence for each of eight pillars, security among them. The assessment asks for your work email and sends you the report link once. You can run three checks per hour per connection.

Security carries 12% of your score, and your report shows it. The assessment reads your homepage plus up to eight sampled pages, looking at your response headers, markup and scripts, so your security evidence is what those pages send to a browser. Compare your report with the header list above. You will see which names your site is missing. And those gaps are your quickest wins.

Your overall score puts you in a band: 80 to 100 good standing, 60 to 79 constrained, 40 to 59 at risk, and 0 to 39 legacy condition. The assessment does not log in to your site, read your analytics, pull your field performance data or interview you. Want to know whether your database is open? Look in your own backend settings, because the answer lives only there.

Questions, answered.

Check your own site.

1. 01Website repairDown, hacked or broken: what survives, what to rebuild.
2. 02Website health checkThe general read, all eight pillars.
3. 03Website audit checklistThe eight pillars as a list you can run yourself.

More from What Ships.

1. 01AI code vs human code: what the difference looks like on a live website.Evidence · 2026-10-25
2. 02How to build a website with AI without the mistakes everyone makes.Guide · 2026-10-25
3. 03Build a website with Claude: what you get, and what to check before launch.Claude · 2026-10-25