The 6 most common security findings in vibe-coded apps, measured rather than guessed

dangerouslySetInnerHTML topped the list at 42.6% of repos. React names it dangerously for a reason: it injects raw HTML, and if any of that HTML ever derives from user input, it's cross-site scripting. Generated code reaches for it because it's the shortest path to rendering rich content. The fix: render text as text, and when you do need HTML, sanitise it with a maintained library like DOMPurify before it goes in. Never interpolate user input into it raw.

Numbers two and three are the same discipline failing twice: 35.7% of repos have a .gitignore that doesn't cover .env files, and 15.3% have no .gitignore at all. Both are prevention failures. The repo may be clean today, but nothing stops tomorrow's .env commit. The fix takes minutes: add a root .gitignore covering .env, key files, and your stack's build artifacts. It's the single cheapest security improvement in this study, which makes its absence in 15% of repos the quietest bad news in it.

curl-piped-to-shell appeared in 9.8% of repos: an install step that downloads a script from a URL and executes it immediately, usually in a README or setup script. You're running unreviewed remote code with your local privileges, and the script can change after you've vetted it. The fix: download first, read it, pin to a specific version or checksum, then run. Or take the package-manager install the project almost always also offers.

Hardcoded passwords also hit 9.3% of repos: a password literal sitting in committed code. This is the finding that overlaps with the study's scariest aggregate, the 20.4% of repos with at least one secrets finding of some kind. The fix is the standard two-step. Move the value to an environment variable, and if the repo is public, rotate the credential first, because git history keeps what you committed and deletion alone doesn't end the exposure.

Wildcard CORS (Access-Control-Allow-Origin: *) showed up in 11.3% of repos. We originally listed it as a security finding. A reader challenged that, and they were right, so here's the correction.

On its own a wildcard gives an attacker nothing. Browsers refuse to attach cookies to a request whose response allows any origin, so a malicious page reading your API learns exactly what a logged-out visitor could have fetched anyway. If the data is public, this is a non-issue.

It turns dangerous in one specific pairing: a wildcard plus credentials. We tested four libraries. FastAPI/Starlette, flask-cors and django-cors-headers all quietly rewrite that '*' into whatever origin asked, and send Access-Control-Allow-Credentials: true alongside it, which the browser will hand over. Express's cors package doesn't; it sends a literal '*' and the read gets blocked. So the same config is a real hole in Python and a shrug in Node.

We went back through all 120 wildcard hits to see which were which. 40 weren't running code at all: markdown, prompt-library templates, another scanner's rule definitions, good/bad teaching snippets. 76 were bare wildcards with no credentials. Two repos were exploitable. That's 0.4%, against the 11.3% we'd published. One repo we'd flagged had shipped a guard that refuses to boot on the invalid combination, and we'd cited its own warning message back at it.

So the scanner now reports the wildcard only where it's paired with credentials. A bare one produces nothing at all. We dropped that check rather than hand you 42 findings that all resolve to "this is probably fine". Treat the 11.3% as a measure of what AI codegen emits by default rather than a count of vulnerable apps.

All six findings survive the does-it-run feedback loop, because none of them stops an app working. That's also what makes a rules-based scan the right instrument: the patterns are fixed, so they count cleanly. About this study: 549 public repos self-described as AI- or vibe-coded, scanned by the quality·vibes rules engine, data collected July 2026. Per-rule reporting caps mean the per-repo counts behind these percentages are floors.