{"slug": "it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built", "title": "It Compiles. Nobody Asked If It Was Safe: The One-Afternoon Review for an AI-Built App", "summary": "Veracode's 2026 GenAI Code Security Report, covering code from more than 100 models, found AI-generated code compiled almost every time but passed security checks only about half the time when tested without security-specific prompting on raw models. The report's mechanism is illustrated by two public cases: Matt Palmer's 2025 scan of 1,645 Lovable showcase projects, published as CVE-2025-48757, and Wiz's 2026 disclosure that a publishable Supabase key exposed Moltbook's production database for unauthenticated read and write because Row Level Security was missing. Wiz researcher Gal Nagli wrote that the exposed publishable key \"does not automatically indicate a security failure,\" with the real failure being the absent database rule.", "body_md": "*In Veracode's 2026 testing, AI-generated code compiled almost every time and passed security checks about half the time — with no security prompting, on raw models. Two public cases — a scan of Lovable's showcase in 2025 and Wiz's Moltbook disclosure in 2026 — show one shape a failure can take: a key that is meant to be public, and a server-side rule that was missing or wrong. Here is the mechanism, what the record actually establishes, what it does not, and the afternoon that checks for it.*\n\nSomebody on your side of the table shipped an app this quarter that no security person ever read. A client intake portal. A technician's internal tool. A dashboard built in an afternoon with an AI coding assistant and a login page that made it feel finished.\n\nIt works. I believe you. That is not the question any more.\n\nVeracode's *2026 GenAI Code Security Report* (press release, July 28, 2026) tracks code generated by more than 100 models. By Veracode's numbers:\n\nTwo conditions ride with those numbers and they matter: the tests used **no security-specific prompting**, and they ran against **raw models** — not agents, not tools with guardrails, not code a human reviewed. Veracode says so explicitly.\n\nSo the honest reading is not \"AI code is insecure.\" It is narrower and more useful: **code that nobody asked about security, and nobody reviewed, passes security checks about half the time.** Our read: that describes a lot of the apps quietly going live inside small businesses right now.\n\nMany of these apps put their data in a hosted database — Supabase is a common one — and the browser talks to it directly. To do that, the page carries a key.\n\nHere is the part people get backwards: **that key is supposed to be public.** A publishable (or \"anon\") key is designed to sit in the browser. Anyone can read it. That is fine, because the key is not the lock.\n\nThe lock is a rule on the database itself — in Supabase, a **Row Level Security** policy — that says *this user can read these rows, and only these*. When the rule exists and is right, the public key is harmless. When the rule is missing or wrong, the public key opens the whole table, for anyone, without logging in. And nothing on the screen looks any different.\n\nThat is the entire mechanism behind both cases below.\n\nIn March 2025, Matt Palmer — who works in developer relations at **Replit**, which builds a competing AI app builder; read the finding with that in mind, and read his method yourself — found a Lovable-built site that would hand over its whole `users` table when a request was edited to ask for everything. So he and a colleague checked the rest.\n\nLovable keeps a showcase page of launched projects. Their script visited the homepages of **1,645** projects listed there, captured each request to the database, and re-issued it asking for everything. Per Palmer's published statement:\n\nHe is careful about the method, and so are we: the script **only analysed homepages**. It never logged in and never crawled deeper. Our read: that count is a floor, not a ceiling.\n\nIt was published as **CVE-2025-48757** on May 29, 2025. Palmer also writes (as of May 2025) that Lovable's later \"security scan\" checked *that* an RLS policy existed, not *whether it was correct*. That is his assessment — but hold onto the underlying point, because it comes back below.\n\nIn January 2026, Moltbook — a social network for AI agents that had just gone viral, and whose founder said publicly he had vibe-coded it — got a visit from Wiz researchers who, in their words, were \"simply browsing like normal users.\"\n\nWithin minutes they found a Supabase key in the site's client-side JavaScript. Wiz is precise here: it was a **publishable** key, and exposing one \"does not automatically indicate a security failure.\" The failure was behind it — no Row Level Security. Per Wiz's write-up (Gal Nagli, February 2, 2026), that key gave unauthenticated **read and write** access to the production database:\n\nMoltbook secured it **within hours** of Wiz's report, over several rounds of fixes, and Wiz deleted the data it had accessed. This was a **research disclosure**, not an attack report. (Wiz notes that researcher Jameson O'Reilly independently found the same misconfiguration.) Wiz's own summary is the line worth keeping: the issue \"ultimately traced back to a single Supabase configuration setting.\"\n\nNeither case is new in kind. OWASP's Top 10:2025 keeps **Broken Access Control at #1**; in OWASP's contributed test data, every application tested had some form of it. And OWASP states the principle plainly: access control is only effective when implemented in **trusted server-side code**.\n\nOne of OWASP's own example scenarios is an app that keeps its access checks in the front end — JavaScript that stops you navigating to the admin page — while the admin URL itself still answers a direct request. The attacker never clicks the button. They call the route.\n\nOur read: this is the pattern an assistant ships most easily, because it builds exactly what was asked for: a page, a hidden button, a redirect for non-admins. It all looks right in a demo. Nothing in the demo asked the server to refuse.\n\nIt is worth being honest about the edges of the record.\n\nWhat does hold across both: a rule that *exists* is not a rule that *works*, and the only way to know which one you have is to try it — from the outside, as somebody who should not get in.\n\nOne app. The one a real person can sign into today. Put whoever built it in the room.\n\n```\nTHE PRE-LAUNCH AFTERNOON — ONE APP\n1  PICK     one app a real person can sign into.\n2  SECRETS  search the BUILT front end (view source,\n            network tab, build output) — not the repo —\n            for keys. Publishable key: fine.\n            Service / admin key: remove it,\n            redeploy, rotate, treat as exposed.\n3  ROWS     for every table the browser can reach,\n            confirm the row rule EXISTS, then prove it\n            WORKS with two test accounts: B's record\n            as A, and with no session; read AND\n            write. You should get nothing back.\n4  ROUTES   call the admin API directly as an\n            ordinary user. Expect a refusal (401/\n            403/404) or empty result, never data.\n5  HOW      every PASS gets a How-verified line, a date\n            and a named human.\n```\n\nStep 5 is the one that turns an afternoon into evidence. \"The assistant said it did\" is not a how. \"Called `/api/users/2` as user 1, got 403, 2026-09-29, J. Smith\" is.\n\nTwo ground rules. Run this **only on apps you own or are authorized to test**. And if a check returns data that should not have been readable, treat it as a potential exposure — follow your incident-response plan and bring in counsel and your insurer; notification duties are a legal question, not a checklist one.\n\n**The free kit:** *The Vibe-Coded App Pre-Launch Kit* (Gatorbyte #015) is this afternoon on paper — 26 controls in six groups, the five things the login page probably forgot, a legal and trust pass, a review-only prompt for the assistant that built the app, and a pre-launch register with a How-verified column. Runs offline as a portable Windows app; no account, nothing phones home. Free to use inside your organization and with your clients, including in paid engagements.\n\n→ [https://thesecuritygator.gumroad.com/l/gb015-vibe-coded-app-prelaunch-kit](https://thesecuritygator.gumroad.com/l/gb015-vibe-coded-app-prelaunch-kit)\n\n*The kit supports secure-development, pre-release review and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for a penetration test or an application security assessment. The Security Gator is not affiliated with Veracode, Wiz, OWASP, Replit, Lovable or Moltbook.*\n\n**Sources:**", "url": "https://wpnews.pro/news/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built", "canonical_source": "https://dev.to/biggthecreator/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built-app-42kg", "published_at": "2026-09-30 14:07:00+00:00", "updated_at": "2026-09-30 14:16:59.705761+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "ai-products", "large-language-models"], "entities": ["Veracode", "Lovable", "Supabase", "Moltbook", "Wiz", "Matt Palmer", "Replit", "Gal Nagli"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built", "markdown": "https://wpnews.pro/news/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built.md", "text": "https://wpnews.pro/news/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built.txt", "jsonld": "https://wpnews.pro/news/it-compiles-nobody-asked-if-it-was-safe-the-one-afternoon-review-for-an-ai-built.jsonld"}}