Windsurf Committed API Keys and Secrets to Git Repository
Windsurf's Cascade assistant hardcoded API keys, database credentials, JWT secrets, or other sensitive values directly into your source code, and those files were committed to your Git repository. Even if you delete the secrets now, they remain in your Git history and may already be compromised.
This is one of the most common and dangerous security issues with AI-generated code. Cascade focuses on making things work, so when it needs an API key or connection string, it may place the value directly in the code rather than referencing environment variables.
GitHub, GitLab, and other platforms actively scan for leaked credentials, and automated bots scrape public repos for secrets within minutes of them being pushed. If your repo is public, assume any committed secrets have been compromised.
Error Messages You Might See
Common Causes
- Hardcoded connection strings — Cascade wrote database URLs with username and password directly in config files
- API keys in source files — Third-party API keys (Stripe, SendGrid, OpenAI) placed directly in service files instead of environment variables
- JWT secret in auth code — The JWT signing secret was hardcoded in the authentication middleware
- Missing .gitignore entries — Cascade created .env files but didn't add them to .gitignore, or placed secrets in files that aren't typically ignored
- Config files with real values — Configuration files contain production credentials instead of placeholder values
How to Fix It
- Rotate ALL exposed secrets immediately — Generate new API keys, change passwords, and create new tokens for every credential that was committed. The old ones must be considered compromised
- Move secrets to environment variables — Replace every hardcoded value with process.env.VARIABLE_NAME or the equivalent for your framework
- Create proper .env and .gitignore — Add a .env file for local development and ensure .env* is in .gitignore. Create a .env.example with placeholder values
- Clean Git history — Use git-filter-repo or BFG Repo Cleaner to remove secrets from past commits if the repo is private. For public repos, assume the secrets are already compromised
- Install pre-commit hooks — Add tools like git-secrets, detect-secrets, or gitleaks as pre-commit hooks to prevent future credential commits
- Enable GitHub secret scanning — Turn on GitHub's secret scanning alerts in your repository settings to get notified of exposed credentials
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 just delete the file with secrets and push again?
No. Deleting the file only removes it from the latest commit. The secrets remain in your Git history. Anyone with access to the repo can find them in previous commits. You must rotate the credentials and optionally rewrite Git history.
How do I prevent Cascade from hardcoding secrets in the future?
Include instructions in your Cascade prompts to use environment variables. Create a .env.example file early in the project, and add a pre-commit hook like gitleaks that blocks commits containing credential patterns.