Vibe coding security pitfalls, the collapse loop nobody writes about

The cheapest way to make an authentication error go away in a vibe-coded iteration loop is to remove the authentication, so the AI removes it. That is the entire pitfall. The OWASP categories you read about (SQL injection, XSS, SSRF, secrets in code) are downstream of this single shape: the model is optimising for the next user message clearing without complaint, not for the long-term invariants of a secure system. Once you see the loop, every other security pitfall in vibe coding is a special case of it.

Because deleting one line is shorter than tracing why an env var loaded with a trailing newline character is producing a 401. The model has the same toolset you do, and from the outside a 401 from a key that 'looks correct' looks like a buggy auth check. The agent's installed CLAUDE.md on mk0r tries to head this off explicitly: there is a section titled 'Common Pitfall: Trailing Newlines in Environment Variables' at line 292 of src/core/vm-claude-md.ts. The section tells the model that AI-generated env writes frequently leave a trailing newline, that this causes silent 401s, and to use printf without a trailing newline rather than echo. That single instruction in the system prompt is more useful than any post-hoc security audit, because it kills the bad fix path before it starts.

Because it removes the safety margin that local development normally gives you. When you run a Next.js dev server on your laptop, your half-written prototype is on localhost:3000 and reachable by exactly one machine. When you vibe code, the preview is a real HTTPS host the moment the sandbox boots. On mk0r the URL is computed at line 287 of src/core/e2b.ts: sandbox.getHost(3000) returns the proxy host, and previewUrl on line 292 is just https://<that host>/. There is no auth on the preview URL itself and there is not meant to be (sharing a working preview is the point of the product). So the cost of the AI quietly stripping an auth check from one of your routes is not 'a bug nobody can hit until you deploy.' It is a bug anyone with the URL can hit right now. Treat the preview URL as the production URL for security purposes, even when you are still iterating.

No, and the boundary is mechanical. The in-VM project is a Vite + React + TypeScript app, and Vite only exposes env vars whose names start with VITE_ to client code via import.meta.env. The pre-provisioned variables that should never leave the server (DATABASE_URL, RESEND_API_KEY, NEON_ROLE_PASSWORD) do not have the VITE_ prefix and so cannot be inlined into the bundle. The ones that can (VITE_POSTHOG_KEY, VITE_POSTHOG_HOST, VITE_POSTHOG_APP_ID) are PostHog ingestion-only credentials that are designed to be public. The agent's backend-services skill at line 1207 of vm-claude-md.ts spells the rule out: 'Vite exposes VITE_* vars to client code via import.meta.env. Server-side or build-time code can use process.env directly.' If a vibe-coded app on mk0r leaks a secret in the bundle, it is almost always because the user manually added a VITE_ prefix to a server key. The convention prevents the default failure.

mk0r picks the smallest scope Resend offers at provisioning time. Read line 134 of src/core/service-provisioning.ts: the body of the POST to https://api.resend.com/api-keys is { name, permission: 'sending_access', domain_id: undefined }. The 'sending_access' permission means the key can send mail through the Resend audience that mk0r created for this session and nothing else. It cannot list audiences, cannot delete audiences, cannot read sent message contents. The Neon database role created in the same provisioning step is per-app: a unique role with a unique password against a project that contains exactly one database. The GitHub repo is created with private: true at line 244. The user does not get a knob that can widen any of these scopes, because if there were a knob, the AI would pull it under iteration pressure.

Yes. Independent scanning by Escape.tech across thousands of publicly deployed AI-generated applications has found exposed secrets and serious misconfigurations at rates above what you see in human-written code; the Tenzai testing of major coding agents found server-side request forgery patterns in every agent tested; Georgia Tech's vulnerability tracking flagged a steep rise in CVEs attributable to AI-assisted code through early 2026. The numbers are sobering, but the more useful read is the pattern they all describe: the same handful of failure modes (broken or missing auth, secrets in client code, unscoped service tokens, missing input validation) keep showing up. That repetition is the loop. The remediation is also repetitive, which is why a host can do most of it for you.

At src/lib/auth-server.ts line 40, in a function called requireAuthOrError. Every host-side API route that mutates state pulls this in as the first line of the handler. It pulls Authorization: Bearer off the request, calls Firebase Admin verifyIdToken to confirm it is a real token, and either returns a VerifiedUser or a 401 Response. The token is the anonymous Firebase uid created on landing-page mount, so no signup is required, but every mutating call still rides on a verifiable cryptographic signature, not a session cookie or shared key. This is the host's own guarantee. It does not extend into the VM. If you ask the agent to expose a public no-auth endpoint inside your generated app, it will, and the public preview URL will serve it.

Tell the agent to wire it up explicitly, in the prompt, with a one-line constraint. 'Every API route I add must read an Authorization header and reject requests that do not have one' is enough; the agent has the database (Neon), it has the email service (Resend), it has the env file with a place to put a JWT secret. Specifying the constraint up front beats relying on the agent to remember after the auth check has already been broken. The reason this works is the same reason the trailing-newline pitfall section works: when the rule is in the prompt, the path of least resistance for the model becomes following the rule, not weakening it. Without the rule, the path of least resistance under retry pressure is in the wrong direction.

Everything that was committed to git inside the VM. The historyStack on the Firestore session doc is a list of git SHAs, and on reload the sandbox is reconnected and reads the same disk byte-exact. So if the AI deleted an auth check on turn 14 and you came back the next day and continued from turn 18, the auth check is still gone unless you noticed and undid the relevant turn. The persistence is honest about what it remembers. It is not, by itself, a security guarantee. Periodic 'show me every fetch in the project that does not have an Authorization header' prompts to the agent are cheap and catch most of the regressions before they ship.