Vibe Coding Security: A Real App, 35 Issues Found

Quick answer: vibe coding security is usually weaker than it looks, because tools like Lovable, Bolt.new, v0, and Cursor generate code that works, not code that's been checked for safety. We ran a real vibe-coded app through a free FlawPilot scan and found a perfect 100 on performance sitting right next to six high-severity security gaps nobody had noticed.

Jump to: the scorecard, what it got right, what was hiding underneath, why this is the default (not a fluke), what to actually do about it, and a quick FAQ at the end.

Picture the last app you shipped with one of those tools. It works. You've clicked through every screen. You've probably already sent the link to a friend, an investor, or your first ten users, and nobody's said a word. As far as you can tell, it's done.

Here's the part nobody tells you: "works when I click around it" and "secure" get checked by two completely different people, and for most vibe-coded apps, the second person never shows up. So we played that person. We took a real, live app, built exactly the way most people build now (fast, with an AI coding tool, shipped without a second thought) and ran it through FlawPilot, our free scan that checks a site's security, performance, infrastructure, and SEO in about two minutes, no login required. We won't name the app, but every number below is real, pulled straight from its report.

The scorecard

67 out of 100. "Needs attention." 269 points out of a possible 400, spread across four areas, and 35 things sitting open: 1 critical, 6 high, 19 medium, 9 low.

Split out, it reads like this:

• Security: 70/100. Needs attention. 16 findings.
• Performance: 100/100. Excellent. Zero findings.
• Infrastructure: 54/100. At risk. 10 findings.
• SEO & Discoverability: 46/100. At risk. 9 findings.

Nobody's data was leaking. The site loads fast. Nothing was on fire. That's exactly what makes this useful instead of a scare story: this is what "looks completely fine" actually looks like once you stop looking at the screen and start looking at what's underneath it.

Let's start with what it got right

A perfect 100 on performance is not nothing. Zero findings across Core Web Vitals, page weight, render-blocking assets, and caching, all clean. AI-generated frontends tend to be genuinely fast, because modern scaffolding tools bundle and lazy-load sensibly without anyone having to ask.

Which is exactly what makes the rest of this report worth reading instead of skimming. Speed is the one thing you'd have noticed yourself, just by using the app. Everything below is the kind of thing nobody notices, until someone goes looking for it on purpose.

What was hiding underneath

So here's what "somebody went looking" turned up.

Anyone could send an email pretending to be this company. Rated High, and the reason is almost funny in how small it is: there's no DMARC record on the domain. Without one, mail servers have no way to check whether an email claiming to be from the company is actually from the company. A phishing email spoofing their own domain sails straight through, no questions asked.

There was no protection against injected scripts. No Content-Security-Policy header, also High. A CSP is the fence that stops a malicious script from running loose in a visitor's browser if it ever lands on a page, whether through a compromised third-party widget or a stored XSS bug. There was no fence.

Visitors weren't forced onto the secure connection. No Strict-Transport-Security header means a visitor's very first request to the site can get quietly downgraded to plain HTTP: readable, alterable, before HTTPS ever kicks in. High again.

The site could be loaded inside someone else's page. No clickjacking protection, meaning anyone can embed the real site invisibly behind a fake one and trick people into clicking things they never meant to click.

Underneath those four sat a stack of Mediums that all tell the same story: nobody was watching DNS and email configuration, the infrastructure side of the report that's easy to forget exists. Any certificate authority could issue an SSL cert for the domain, no CAA record stopping them. Outgoing mail was at real risk of landing in spam, no DKIM signature to vouch for it. There wasn't even a robots.txt file, so crawlers were making it up as they went, which also dragged the SEO score down to 46. And the server was cheerfully announcing its exact software version to anyone who asked, a small, free gift to whoever's searching for a matching exploit that week.

Nothing on this list shows up when you click around the app. All of it shows up the second something outside the team (a bot, a scanner, an actual attacker) bothers to check.

This wasn't a fluke. It's the default.

That exact combination (no CSP, no HSTS, no clickjacking protection, no DMARC) is close to the single most repeated pattern across apps built with Lovable, Bolt.new, v0, and Cursor. Not because these tools are careless. Because none of them are optimizing for this. They're optimizing for "does this satisfy the prompt," and a missing security header doesn't stop the app from running, so it never makes the cut unless someone specifically asks for it.

The research backs it up. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 coding tasks in Java, JavaScript, Python, and C#, and found that AI-generated code introduced exploitable security flaws in 45% of tests, with no improvement as the models got newer or better at writing functional code. Java came out worst at a 72% failure rate, and defenses against cross-site scripting failed in 86% of relevant samples. None of that is spread evenly across every possible mistake, either. It clusters right here: cheap to fix, meaningful to skip, invisible until it isn't. That's really the whole story of vibe coding security in one sentence: not that the code is bad, but that nobody drew a line between "it runs" and "it's safe to put in front of strangers."

It's not just a lab finding. In March 2025, a missing Row-Level Security policy in Lovable-generated apps was catalogued as CVE-2025-48757, CVSS 9.3, and it left more than 170 live production apps with databases that any unauthenticated visitor could read, write to, or delete from, just by inspecting the app's own network requests. Nobody wrote a bug that broke the app. The gap was a security control nobody had reason to think about, sitting quietly under an app that worked perfectly for months.

The thing that used to catch this was a senior engineer, quietly flagging it in code review. That role mostly doesn't exist in a vibe-coded workflow, because there's often no review step between typing a prompt and the app going live. Nobody removed that safety net on purpose. It's just gone, and nothing replaced it yet, so the gap sits there until a scan, a scanner bot, or a worse kind of visitor finds it first. Researchers at Stanford ran this exact scenario in a controlled study back in 2023 and found something worth sitting with: developers using an AI coding assistant wrote measurably less secure code than developers working without one, and they were more confident their code was secure, not less. The tools don't just introduce the gap. They make it easier to feel like there isn't one.

This is the general shape of AI generated code security in 2026, not something unique to one framework or one region. Whether it's a Lovable prototype, a Bolt.new MVP, or a Cursor-assisted rewrite of an existing app, the same handful of headers, DNS records, and configuration checks keep turning up missing, because none of the coding assistants were built to reason about a threat model. They were built to reason about your prompt, and a threat model was never part of the prompt.

Found it. Now what?

A list of severity labels is only useful if it turns into something you actually do. So here's how FlawPilot handles that, on this exact report.

Every finding gets grouped by area and dropped into a "What to do next" list, ranked by what actually matters most, not a raw dump of jargon. Item one on this report was the DMARC finding, and right next to it, in plain English: add a DMARC record to your DNS to stop email spoofing. Nothing to look up. Nothing to decode.

That's the whole idea. Most security tools stop at "here's what's broken" and leave you to go figure out the rest. FlawPilot's free report hands you the fix for the top issue in every area, spelled out, at no cost. Past that (and for a full crawl of the site instead of a handful of representative pages), Logicwind's team builds the prioritized remediation roadmap and puts engineers on it directly. Finding the gap and fixing the gap don't have to be two separate projects with two separate vendors.

And here's the part that makes it genuinely worth an afternoon: those four High findings (DMARC, CSP, HSTS, clickjacking) are also four of the cheapest fixes on the entire report. None of it touches application logic. It's DNS records and response headers. Clear those four, close out the CAA and DKIM gaps sitting right next to them, and a security score that opened at 70 is realistically headed for the mid-90s (illustrative, since the exact number depends on what else the fix touches), but the direction isn't in question. Very few afternoons move a number that much.

This is the first in a series we'll be keeping up on this blog: real, anonymized scans, broken down in plain English, no jargon dressed up as education and no bare "check out our tool" pitch. If that's useful to you, this is a good time to bookmark it: there's more coming.