- Cursor is a coding agent, not a host. The risks are in the code it writes and the repository you keep it in.
- The full GitHub check is the most relevant one for Cursor projects. It reads the code, including secrets deleted since but still in the history.
- The quick check covers the deployed live site, wherever you host it.
- Cursor has settings to limit what the AI reads. They do not decide what you commit.
What Cursor is and how its apps are deployed
Cursor describes itself as a coding agent for building ambitious software. You install it as a desktop app, and it also has a command line tool and cloud agents. It does not host your app. You deploy it yourself, for example on a service you choose, and Cursor has recently added a paid beta called Origin that can host code in repositories. Your code lives in your own git repository, usually on GitHub. Cursor’s GitHub app is what lets features like cloud agents work with your repositories.
Common security issues in Cursor apps
These are patterns that are common in AI-built apps, not claims about any one app. The rating is what LetMeCheck would typically give the issue (Critical, High or Medium).
- CRITICALCHECK: SECRET KEYS SAVED IN CODE
1. Hardcoded secrets and committed .env files
What it is: A key typed straight into the code, or a .env file (the file that holds your settings and keys) that was committed to git. Both are exposed keys waiting to leak. See also exposed .env files.
Why it happens here: To make a feature run, an agent may write the key inline or create a .env file. Cursor’s ignore file controls what the AI can read, and Cursor’s own docs say complete protection is not guaranteed. It does not control what git commits.
How bad it can get: Deleting the key later does not remove it from git history. Anyone who can read the repository, or a leaked copy of it, can use the key.
- CRITICALCHECK: PAGES AND ROUTES THAT SKIP THE LOGIN CHECK
2. Routes with no server-side login check
What it is: An API route is a web address your app answers. If the route does not confirm on the server who is asking, anyone can call it directly.
Why it happens here: An agent adds a route to feed a screen, and the screen checks the user. The route itself often does not. Cursor’s own rules docs say AI guidance should not be your only security control.
How bad it can get: Anyone can read or change data by calling the route, with no account at all.
- HIGHCHECK: PACKAGES WITH KNOWN SECURITY HOLES
3. Packages that do not exist, or that someone registered later
What it is: AI models sometimes suggest a package name that sounds right but does not exist. An attacker can register that name with harmful code. These are hallucinated packages.
Why it happens here: Models predict plausible names. Install commands run without anyone checking that the package is the real one.
How bad it can get: Harmful code runs on your computer or your server when you install it.
- MEDIUMCHECK: PACKAGES WITH KNOWN SECURITY HOLES
4. Outdated packages with known holes
What it is: Real packages whose installed version has a publicly known security hole.
Why it happens here: The agent installs whatever version it knows from its training, which can be old. Nobody revisits it afterwards.
How bad it can get: Known holes are listed publicly, so attackers can look for them.
- MEDIUMCHECK: LIMITS ON LOGIN ATTEMPTS
5. No limit on login attempts
What it is: Without a cap, a script can try passwords against one account all day. This is missing rate limiting.
Why it happens here: An agent builds a working login form. Rate limits are a separate feature that nobody asked for.
How bad it can get: Weak passwords get guessed, and your server can be hammered with requests.
- CRITICALCHECK: WHO CAN READ AND CHANGE EACH DATABASE TABLE
6. Database queries built from user input
What it is: The code sticks what a visitor typed straight into a database command, which is how SQL injection works. It can also mean tables with no access rules at all.
Why it happens here: String-built queries are the shortest code, and a quick prompt rarely asks for safe ones.
How bad it can get: An attacker can read or delete data the page was never meant to give out.
How LetMeCheck checks a Cursor app
Quick check: give it the address where you deployed the app. Cursor does not host anything, so this is whichever service you chose. It looks at the live site from the outside and can flag what any visitor can see, such as a key in the page code. Free, read-only, no sign-up.
Full check: this is the one that matters most for Cursor. Connect GitHub to LetMeCheck with read-only access and pick the repository. It reads the code for secret keys (including ones you deleted but that are still in the history), who can read and change each database table, packages with known holes, and routes that skip the login check. If you keep the code only on your own machine, push it to a private repository first.
The fix prompt is written to be pasted into a Cursor chat or agent. Tell it which file and route to change, review the diff it proposes, and run the check again to confirm. A short rule in your Cursor rules file, such as “never hardcode keys”, helps stop it coming back.
The quick check is free, needs no sign-up and is read-only. See pricing for what the paid plans add, or try the free website audit now.
Example report entry
EXAMPLE, NOT A REAL CUSTOMER RESULT
A secret key is saved in your code, and in its history
A payment key was typed into a file and committed. It was removed in a later commit, but it is still readable in the repository history. This is a made-up example to show the format of a report entry.
In this repository, remove the hardcoded payment key from src/lib/pay.ts and read it from an environment variable instead. Add .env to .gitignore, add an .env.example with empty values, and tell me which key I need to rotate.
5 steps to harden a Cursor app before launch
- 1Add .env and similar files to .gitignore before your first commit, and check that no key is typed into a source file.
- 2If a key was ever committed, rotate it. Deleting the file does not remove it from git history.
- 3For every API route, confirm the server checks who is calling, not only the screen.
- 4Read each new package name before you install it, and check it is the real, maintained one.
- 5Connect GitHub, run the full check, fix what it finds, and run it again. Add a rule to your Cursor rules file so new code does not hardcode keys.
When to get a developer
If a key has been public for a while, or your routes need a proper sign-in layer, bring in a person. A vetted developer who knows Cursor projects can clean up the history, add the checks and give you a fixed quote before work starts. LetMeCheck re-checks afterwards. See hire a developer.
Frequently asked questions
Does Cursor hide my secrets?
Cursor has an ignore file and privacy settings that limit what the AI reads. Its docs say complete protection is not guaranteed, and these settings do not decide what git commits. A key you committed is still in your repository.
Which LetMeCheck check should I use for a Cursor project?
The full check on your GitHub repository, because Cursor’s risks are in the code. Use the quick check as well on the live site, wherever you deployed.
Can LetMeCheck see my code if I only use Cursor locally?
Not until it is in a GitHub repository you connect. The quick check still works on the deployed site, but only the full check reads code.
What is a hallucinated package?
A package name an AI suggests that does not exist, or that an attacker has since registered. See hallucinated packages. The full check looks for packages with known holes.
Does LetMeCheck replace Cursor’s own security tools?
No. Cursor has review tools of its own. LetMeCheck is a separate check with plain-English results and fix prompts, which you can use alongside them.
Check your Cursor app now
Run the quick check on your live site in about a minute, with no sign-up. Connect GitHub (read-only) when you want the full check.
Other platforms
Sources
- Cursor (checked 2026-11-03)
- Cursor docs: Quickstart (checked 2026-11-03)
- Cursor docs: Ignore files (checked 2026-11-03)
- Cursor docs: Rules (checked 2026-11-03)
- Cursor docs: Agent security (checked 2026-11-03)
- Cursor docs: Security agents (checked 2026-11-03)
- Cursor docs: GitHub integration (checked 2026-11-03)
- Cursor changelog: Origin code hosting (checked 2026-11-03)
- Cursor: hallucination limits (checked 2026-11-03)
Platform behaviour changes fast. Last reviewed: . Spotted something out of date? Tell us.