AI & TechnologyCursor App Rescue: 7 Problems to Fix Before Launch

Cursor writes code in your own repository, so the problems that show up with real users are ordinary web app problems that are easy to miss without a review: secret keys, unprotected endpoints, open database rules, unchecked packages and settings that differ between your machine and the host. Unlike Lovable, Bolt or Replit, Cursor doesn't host your app or pick your database. That gives you more control, and it also means no platform check runs before you launch.

Below are the seven problems to check before launch, how to test each one, and how to fix it. The facts come from Cursor's documentation and forum, the Next.js, Vercel, Supabase and Firebase docs, OWASP, NVD and one research paper, and I re-read each source on October 20, 2026. The examples use Next.js, but the checks apply to any stack. The how-to-check and how-to-fix steps are my own advice.

1. Secret keys in the browser or in git

In Next.js, a variable whose name starts with NEXT_PUBLIC_ "will be inlined into any JavaScript sent to the browser." If the agent puts a secret there to make a feature work, every visitor can read it. Supabase is blunt about its secret keys: "A secret key bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control."

Cursor can also read your .env file. A Cursor staff reply on its forum explains that .env* is in the default ignore list, "but that list only applies to indexing", and Cursor's docs say the terminal and MCP tools used by the Agent "cannot block access to code governed by .cursorignore".

How to check: search the code and the git history for service_role, sb_secret_, sk_live and your providers' key prefixes. List every NEXT_PUBLIC_ variable and ask whether each one is safe to publish. Open the JavaScript your live site loads and search it for the same prefixes.

How to fix: rotate every key that was ever in browser code or git, move secrets to server-only code and the host's environment settings, and keep production secrets out of the project folder.

2. API routes and server actions anyone can call

Hiding a button doesn't protect the action behind it. The Next.js data security guide says a Server Action "is reachable via a direct POST request, not just through your application's UI," and that "A page-level authentication check does not extend to the Server Actions defined within it." OWASP calls the related flaw insecure direct object reference (IDOR): attackers "access or modify objects by manipulating identifiers", such as changing an ID in a request to read another user's record.

How to check: for every API route and every 'use server' function, confirm it checks the session and that the record belongs to that user. Call each one while logged out, then as user B with user A's IDs.

How to fix: check authentication and ownership inside each handler, or in one server-only data layer that every handler uses. Return only the fields the screen needs, and deny by default.

3. Database rules left wide open

If the browser talks to the database directly, the rules are the only thing standing between a stranger and your data. Supabase says: "Enable RLS on every table in an exposed schema." Firebase's own example of an open rule set carries the warning "NEVER use this rule set in production; it allows anyone to overwrite your entire database," and says that without authentication and rules, "anyone who guesses your project ID can steal, modify, or delete the data."

A quick way to make a permission error go away during development is to turn row-level security off or add a rule that lets everyone in. That shortcut is easy to forget before launch.

How to check: on Supabase, open the Security Advisor and search your policies for using ( true ). On Firebase, search your rules for if true and for test-mode dates. Then read and write as a logged-out visitor and as a second user. If your app uses Supabase from the browser, the free scan at the end of this page does the logged-out read test for you.

How to fix: turn on RLS for every exposed table with policies tied to the signed-in user, write Firebase rules that check request.auth, and keep secret or admin keys on the server. The Firebase security guide has worked examples.

4. Packages that don't exist, or aren't what they seem

Code models sometimes suggest packages that were never published. A 2024 study of 16 code models found "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models." Those figures cover models in general, not Cursor in particular. The risk is that someone registers an invented name with harmful code, and the next install pulls it in.

How to check: read every new line in package.json or requirements.txt. Confirm each package exists on its registry, has a real history and the publisher you expect. Run your package manager's audit and commit the lockfile.

How to fix: remove anything you can't account for, install only after checking the registry, and read what the Agent wants to install before you approve it, and don't rely on Cursor's approval prompts alone.

5. Big edits that look right and aren't

Cursor's own guide to reviewing agent code says "AI-generated code can look correct but be subtly wrong," and "Passing tests don't guarantee the code works correctly," because the tests may check the wrong behavior. It recommends small commits, each one a single logical change, so a person can review them.

How to check: read the full diff before you accept it, then run the main user flows by hand: sign-up, sign-in, payment and anything that writes data. Look at which tests cover sign-in, payments and data changes.

How to fix: ask for one change at a time, commit small, and add tests for the money, login and data paths. Test with a second account and realistic data, not only the demo user.

6. Works locally, fails on the host

The .env file on your machine is not on your host. In Next.js, NEXT_PUBLIC_ values are fixed when the app is built: "After being built, your app will no longer respond to changes to these environment variables." Vercel adds that "Any change you make to environment variables are not applied to previous deployments, they only apply to new deployments."

How to check: list every process.env value the code reads and confirm each one is set on the host for production and for previews. Check whether any were added after the last deploy.

How to fix: set every variable on the host, redeploy, read server-only values only on the server, and add a startup check that fails loudly when a required value is missing.

7. An out-of-date editor and unknown MCP servers

The editor itself is part of the risk. NVD lists CVE-2025-54136, where in Cursor "versions 1.2.4 and below, attackers can achieve remote and persistent code execution" by swapping an already-approved MCP configuration for a malicious command (fixed in 1.3), and CVE-2025-64109, where opening a cloned repository in the Cursor CLI Beta could run a malicious MCP server "without any warning". Cursor's security page also says "Cursor supports workspace trust, but it's disabled by default," and calls its run controls "best-effort guardrails rather than a hard security boundary."

How to check: confirm Cursor is on the current version, open .cursor/mcp.json in any repository you cloned, and list the MCP servers you have approved.

How to fix: update Cursor, remove MCP servers you don't recognize, turn on workspace trust, and open repositories you don't trust in a plain text editor first.

What to do this week

1. Search the code, git history and live JavaScript for secret keys, and rotate anything you find.
2. Call every API route and server action while logged out and as a second user.
3. Check your database rules, or run the free leak scan below if your app uses Supabase.
4. Check every package added in the last month against its registry.
5. Compare the host's environment variables with your local .env, then redeploy.

Need a hand?

If you'd rather have someone else check it, the AI-Built App Rescue starts with a $450 Launch Check. You send read-only access, and within 3 business days you get each problem ranked by severity, with where it is and how it was confirmed, plus a fixed price for the Rescue Sprint. The $450 is credited if you go ahead, and you keep the code either way. Built with an app builder instead? See the Lovable, Bolt, Replit, Base44 and v0 checklists. Or send me a short description.