{"slug": "vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps", "title": "Vibe Coding Security Under Test: 100+ Vulnerabilities Across Four AI-Built Apps", "summary": "Astra's Vibe Coding Security Risks Study found 100+ confirmed, exploitable vulnerabilities across four applications built by AI coding platforms Emergent, Lovable, Replit and Base44 from one identical, security-explicit prompt for a FastAPI user-management microservice. Astra's autonomous pentest agents identified each finding, a validator agent retested it, and a human security engineer reviewed it before it was counted, with every finding carrying a CWE mapping, reproduction path and fix. The study also reports a CORS misconfiguration in every app tested and includes a hardened security prompt and a 10-minute browser-only checklist for rate limiting, enumeration, security headers, auth-required routes and CORS lockdown.", "body_md": "**TL;DR**\n\n- Astra’s [Vibe Coding Security Risks Study](https://www.getastra.com/reports/vibe-coding-security-risks-study) is now live.\n- Four AI coding platforms (Emergent, Lovable, Replit, Base44) were asked to build a FastAPI user-management microservice from one identical, security-explicit prompt.\n- We ran our autonomous pentest agents against those builds and surfaced 100+ confirmed, exploitable vibe coding security vulnerabilities.\n- [Grab the full report](https://www.getastra.com/reports/vibe-coding-security-risks-study) for the methodology, the per-platform severity splits, the hardening prompt, the CWE mapping, and the fixes.\n\nVibe-coding platforms let you go from prompt to a deployed app in a single session, a pace that outpaces the review cycles most teams built for slower releases. With Lovable nearing 8 million users by late 2025, and Replit past 50 million by April 2026, we wanted to answer a sharper question than “is vibe coding safe?”\n\nDoes the platform generating the code change the outcome, and does one security prompt give you the same security everywhere? So we gave four of the most-used vibe-coding platforms (Emergent, Lovable, Replit, Base44) one identical, security-explicit prompt.\n\nIt described a FastAPI/Python microservice with bcrypt, JWT access and refresh tokens, Pydantic v2 validation, parameterised queries, slowapi rate limiting, configurable CORS, a four-tier role model, Okta OIDC, and a Slack webhook.\n\nEach app shipped a build, our autonomous pentest went to work, and 100+ confirmed, exploitable vulnerabilities later, the results seemed more consistent than the code.\n\nThe [full report](https://www.getastra.com/reports/vibe-coding-security-risks-study), *The Security Risks with Vibe Coding: A Study*, is live now, along with companion write-ups on the [CORS misconfiguration](https://www.getastra.com/blog/security-audit/cors-misconfiguration/) that turned up in every app we tested and the [Replit-built app](https://www.getastra.com/blog/security-audit/replit-security/) that carried its share of the findings. This post walks through what the research actually says and what to do about it.\n\n## What’s in the Vibe Coding Security Risks Study\n\nThe report is built to be used rather than skimmed. Every finding carries a CWE mapping, a reproduction path, and a fix at the layer where the control actually belongs. In full, the report contains:\n\n- **100+ confirmed, exploitable vulnerabilities** across four AI-built applications, each identified by our autonomous pentest agents, retested by a validator agent, and reviewed by a human security engineer before we counted it.\n- **The per-platform severity split** , with the Critical, High, Medium, and Low breakdowns across 9 vulnerability classes for each of the four builds, so you can see exactly which platform’s app shipped which class of risk.\n- **The hardened security prompt** , written to be pasted as the first message to any vibe-coding tool, with exact thresholds for rate limiting, enumeration prevention, CSP, cookie flags, JWT revocation, row-level authorization, and audit logging.\n- **The universal 10-minute browser-only checklist** for rate limiting, enumeration, security headers, auth-required routes, and CORS lockdown. The appendix adds per-platform checks for Lovable, Replit, Emergent, and Base44 covering the confirmed blind spots in each build.\n- **The four pressure points** we found moved risk the most across platforms: prompt specificity, finding volume versus severity, access control enforcement, and fix complexity.\n\n## Why you should trust this AI code security study\n\nThe methodology was built to close off every usual objection to AI-generated-code critiques (cherry-picked examples, biased pentesters, vendor relationships, prompts rephrased after the fact), before the first scan began.\n\n- One identical prompt used across four platforms without any advance notice to vendors (Emergent’s paid-tier use is disclosed in Section 3 of the report)\n- **Three coordinated AI agents** (Structured Pentest, Bug Bounty Hunter, Validator) attacked each app in parallel, followed by human review. Nothing counted until it cleared the exploitability bar defined in Section 5.4 of the report, which requires reproducible evidence of real impact.\n- A human security engineer validated every finding the autonomous pentest produced, confirming reproducibility and exploitability.\n- We filtered out false positives and unconfirmed findings before the statistics.\n- Pattern identification was done after the fact, with no predetermined list.\n\n## A glimpse at what the pentest found\n\nThe gaps the generators left behind were more consistent than the code they shipped. Nine CWE-mapped vulnerability classes account for most of the 100+ confirmed findings, and five of those classes appeared in every build, regardless of the stack, framework, or auth strategy the generator chose.\n\nCORS misconfiguration was the single most common finding across all four apps, and one platform’s build alone accounted for more than half of those instances. Every app in the study reflected arbitrary request origins back in [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Origin) while allowing credentials, a configuration that lets any external website make authenticated requests on behalf of a logged-in user and read the response.\n\nBroken access control was the most severe category whenever it appeared, and one platform shipped a BOLA that exposed hundreds of user profiles to any authenticated account. The report lays out which platform, how many profiles, and the exact Critical-severity chain.\n\nA typical attack chain in the study looked like this:\n\n1. CORS was configured with a reflected origin, so the API echoed any Origin header back as allowed.\n2. The API accepted credentials alongside that reflected origin, so an attacker’s page could send authenticated requests from any origin and read what came back.\n3. Authorization lived in the frontend React component, so hitting the API with the victim’s session cookie returned data for any user ID in the request path.\n4. No rate limit on that endpoint meant the attacker could enumerate every account on the platform in minutes.\n\nEach of those findings would be filed as medium or low on its own, which is how most scanner tools would categorize them. Chained together, they hand over the user table. The report shows the full chain for every multi-stage finding so you can see what an attacker could actually reach, not only what each individual control missed.\n\n## Who this Report is for\n\n**Founders and CTOs shipping vibe-coded applications** will find the hardened prompt and the universal 10-minute checklist most useful. Both are designed to be used before launch, and both close the universal patterns without needing a security background to run.\n\n**Security teams reviewing AI-generated code security** will find the methodology and the finding-level evidence worth reading. The three-agent pipeline (Structured Pentest, Bug Bounty Hunter, Validator) plus human review is the same pipeline Astra runs against production customer applications, and the chain-of-evidence standard is the same one every AP finding has to clear.\n\n**Pentesters and researchers** will find the per-platform appendix and the CWE-mapped class breakdown useful as a reference point for what AI-coded applications look like under real test conditions.\n\n## So, is vibe coding safe, and which platform is safest?\n\nBoth questions get a cleaner answer inside the report than they will inside a blog post. The study was designed to measure how four platforms responded to the same security-explicit prompt under an identical autonomous pentest, with raw finding counts flattening too much of the per-platform context (severity distribution, CWE class, exploit chain depth, reproduction cost) to stand on their own as a ranking.\n\nThe frame worth taking away is this. Vibe coding security sits at three layers that compound: the prompt specification (what controls you asked for, with thresholds attached), the generated implementation (whether the control landed at the middleware, the data layer, or only in the UI), and the post-generation verification (whether anyone tested the running app before it shipped).\n\nA failure at any one of these layers produces exploitable findings regardless of which platform generated the code, which is why five of the nine shared vulnerability classes in the study showed up in all four codebases.\n\nThe report’s hardened prompt turns Layer 1 into a routine, not expert, task by replacing adjectives with numeric thresholds and named policies the generator can implement.\n\nThe universal 10-minute checklist and the per-platform appendix cover Layer 3, with the exact browser-visible checks for rate limiting, headers, auth coverage, CORS lockdown, and the confirmed blind spots unique to each build.\n\nRead it before you draw conclusions about any one platform.\n\n## Get the report\n\n- [Download the Vibe Coding Security Risks Study](https://www.getastra.com/reports/vibe-coding-security-risks-study) → every finding, every fix, every category, no gating beyond an email.\n- [Meet Astra’s Autonomous Pentest](https://www.getastra.com/autonomous-pentesting) → the engine that produced the findings, pointed at your own application instead of a demo build.\n- [Read the CORS misconfiguration write-up](https://www.getastra.com/blog/security-audit/cors-misconfiguration/) → the deep dive on the single most common finding across all four apps.\n- [Read the Replit pentest write-up](https://www.getastra.com/blog/security-audit/replit-security/) → one platform’s build under independent testing, with the findings laid out in full.", "url": "https://wpnews.pro/news/vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps", "canonical_source": "https://www.getastra.com/blog/security-audit/vibe-coding-security/", "published_at": "2026-11-02 13:37:32+00:00", "updated_at": "2026-11-02 15:22:44.565544+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "ai-products", "artificial-intelligence"], "entities": ["Astra", "Emergent", "Lovable", "Replit", "Base44", "FastAPI", "Okta", "Slack"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps", "markdown": "https://wpnews.pro/news/vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps.md", "text": "https://wpnews.pro/news/vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps.txt", "jsonld": "https://wpnews.pro/news/vibe-coding-security-under-test-100-vulnerabilities-across-four-ai-built-apps.jsonld"}}