Hardcoded API Keys and Secrets in Cursor-Generated Code
After using Cursor to scaffold or refactor your application, you discover API keys, database connection strings, JWT secrets, or third-party tokens hardcoded directly in source files. These secrets end up committed to your Git repository and potentially pushed to GitHub, making them publicly accessible.
This is one of the most dangerous issues with AI-generated code. Cursor's autocomplete and code generation may inline credentials from your context, environment, or prompt history directly into source files rather than referencing environment variables. Bots continuously scan GitHub for exposed keys and can exploit them within minutes of a push.
You might discover this when you receive a security alert from GitHub, an unexpected bill from a cloud provider, or when a dependency scanner flags your repository.
Error Messages You Might See
Common Causes
- AI inlined values from .env context — Cursor had access to your .env file or terminal output and copied actual values into source code instead of referencing process.env
- Prompt included real credentials — You pasted a config snippet with real credentials into the chat, and Cursor reproduced them in the generated code
- No .gitignore for secrets files — .env, .env.local, or config files containing secrets were never added to .gitignore
- Autocomplete suggested full connection strings — Cursor's tab completion filled in a full database URL including username and password from your local context
- Test files with production credentials — Test setup files were generated with real API keys instead of mock values or test environment variables
How to Fix It
- Scan your repository immediately — Run
git log -p | grep -iE '(api_key|secret|password|token|connectionstring)'or use tools like truffleHog or gitleaks to find all exposed secrets - Rotate every exposed credential — Assume any secret that was ever committed is compromised, even if you removed it later. Regenerate API keys, database passwords, and tokens in every affected service
- Move secrets to environment variables — Replace all hardcoded values with
process.env.SECRET_NAMEor your framework's equivalent, and add a .env.example file with placeholder values - Add pre-commit hooks — Install detect-secrets or gitleaks as a pre-commit hook to prevent future secret commits
- Purge Git history if needed — Use
git filter-branchor BFG Repo-Cleaner to remove secrets from your entire commit history, then force push - Configure Cursor rules — Add a .cursorrules file instructing the AI to never inline secrets and always reference environment variables
Real developers can help you.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently Asked Questions
Can I undo a commit that contained secrets?
You can remove the secret from code and make a new commit, but the old commit still exists in Git history. Use BFG Repo-Cleaner or git filter-repo to purge it from history entirely. However, always assume the secret was compromised and rotate it regardless.
How do I prevent Cursor from hardcoding secrets?
Create a .cursorrules file in your project root with instructions like 'Never hardcode API keys or secrets. Always use environment variables.' Also avoid pasting real credentials into the Cursor chat.