Cursor-generated apps: insecure defaults to check before launch

The defaults that ship when code merges without a review loop

Cursor is good at producing working code quickly. The cost is that the working version and the safe version are not always the same, and the human review loop that would catch the gap often gets skipped because the code already runs.

The result is a short list of predictable defaults that reach the production URL. Some of them are visible on the public surface the moment you load the app. Others live only in the route code and need a manual read. This note separates the two, because a launch check can confirm one group and only hint at the other.

These are cursor generated app launch risks worth verifying before the URL spreads, not a claim that Cursor produces insecure code by default.

Four Cursor-specific defaults to verify

Each item below has the same shape: why the assistant tends to produce it, where you can observe it, and the direction of the fix.

• Hardcoded keys and secrets in config or committed files. When a request needs an API key, the fastest path to a working call is to inline the literal value, so the assistant often writes the key directly into a config file, a client component, or a committed .env that was never gitignored. Observable on the public surface: a secret-shaped string can end up in the client bundle or a committed file in a public repo. The fix is to move secrets to server-side environment variables, keep any key that touches the browser limited to a publishable/anon scope, and rotate anything that was already committed, because git history keeps the old value.
• API routes generated without an auth check. Asked to "add an endpoint that returns the user's orders," the assistant produces a handler that queries and returns the data. The auth middleware or the in-handler check is a separate instruction it was never given, so the route returns data before any identity check runs. This is mostly a code-level fact, not a surface fact. A scan can hint at it by finding a data-shaped route that responds without a session, but it cannot confirm the route is missing its auth gate. You confirm that by reading the handler and asking: does anything verify who is calling before the query runs.
• Source maps left on in the default build. Vite and Next.js can emit source maps, and a quick build-and-deploy keeps whatever the default produces. A shipped .map file lets anyone reconstruct your original source from the browser. Observable on the public surface: the bundle references .map files and they load. The fix is to disable source map emission for the production build, or stop serving the .map files publicly. This exposes implementation detail rather than proving exploitation, but internal routes and key-handling logic become readable.
• Overly permissive CORS added to silence a local error. A cross-origin request fails in local development, the assistant adds a wildcard Access-Control-Allow-Origin: * to make it work, and nobody tightens it before launch. Observable on the public surface: the response carries the wildcard CORS header. The fix is to set an explicit allowlist of the origins that actually need cross-origin access. Note the limit: CORS governs which browser origins may read a response, not whether the endpoint requires authentication. A wildcard on a public, non-credentialed endpoint is a smaller issue than a missing auth check on the same route.

What to check from the public URL

Run these against the deployed app, from a normal browser, signed out. Config files can disagree with what the proxy and CDN actually serve.

• Open DevTools, Network tab, hard-reload, and read the response headers on the home page and on any public API route. A response header line of Access-Control-Allow-Origin: * is the suspicious result; an explicit origin or no CORS header on a same-origin route is the safe one.
• In the same Network tab, look at the loaded JavaScript and whether .map files load alongside it. A .map that returns 200 is the suspicious result; a 404 or no map reference is the safe one. Open the Sources panel and confirm you cannot see your original folder structure.
• Search the loaded client bundle and any public repo for secret-shaped strings: long random tokens, sk_-style prefixes, private keys. A live server-side secret reachable from the browser or a public file is a launch blocker. A publishable/anon key that is designed to be public is expected and fine.
• Hit your own data-shaped routes signed out, in a private window. If a route returns real records with no session, treat it as a flag and go read the handler. This is the hint, not the proof. The proof is in the code: confirm whether an auth check runs before the query.

How to fix, and what the fix does not cover

Move every live secret to server-side environment variables and rotate anything already committed, since the value stays in git history. Disable production source maps or stop serving the .map files. Replace any wildcard CORS with an explicit origin allowlist. Add an auth check to every route that returns user-scoped or sensitive data.

Two limits are worth stating plainly. First, fixing CORS or source maps changes the surface but does nothing for a route that is missing its auth check, that is a separate fix in the handler. Second, adding an authentication check confirms who is calling, not what they are allowed to see. A logged-in user reaching another tenant's records is an authorization gap, and that needs its own per-resource check that a header or a login screen will not provide.

Where VibeCodeGuard fits, and what it does not prove

A Launch Check scans the public URL, so it flags the parts of this list that show on the surface: exposed env vars and secret-shaped strings in the client bundle, missing or misconfigured security headers, source maps left accessible, open or wildcard CORS headers, and publicly reachable debug routes that Cursor projects commonly leave open. Each finding comes with severity and a fix direction.

What it cannot do is confirm whether a specific API route is missing its auth check. That is a code-level question. The scan can surface an open data route as a hint, but whether the handler verifies identity before returning data needs a manual read, and whether an authenticated user can reach data they should not is an authorization review beyond the public surface.

Before you share the URL, run a focused Launch Check on the public surface, then read the handlers behind any route that returns sensitive data to confirm the auth check you cannot see from outside.