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.

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.

• 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

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.

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.

Researchers at Stanford found that 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.

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. 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.

Your turn

You don't need a security background to read a report like this one. You need to run the scan. No setup, no coding, no passwords required. Drop in a URL, and in about two minutes you get the same kind of scorecard back: security, performance, infrastructure, and SEO, each out of 100, every finding in plain English, with a toggle between the founder view and the full technical one.

Your app already works. The only question left is whether it's been checked, or just assumed.