What are the best practices for keeping API keys and secrets secure in a GitHub repository?

[neptunealloy52]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code quality

Discussion Details

I’m working on a project hosted on GitHub and want to make sure sensitive information, such as API keys, access tokens, and database passwords, is protected. What are the recommended practices for preventing secrets from being exposed in a repository, especially when collaborating with other developers?

I am Mohammed Kanor and I work at Neptune Alloys. A good starting point is to avoid hardcoding API keys or passwords in your source code. Store sensitive values in environment variables or a secrets manager, and use GitHub Actions secrets for credentials required by automated workflows. Also, add local environment files such as .env to your .gitignore file.

GitHub provides features such as Secret Scanning to help detect exposed credentials and Push Protection to prevent supported secrets from being pushed to repositories. Keep access permissions limited, review your repository’s security settings, and rotate any exposed credentials immediately. Remember that removing a secret from the latest commit does not necessarily remove it from the repository’s history.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[sanjayadanushka712]

A good approach is to separate secrets by environment and never commit real credentials to the repository. For local development, use a .env file excluded through .gitignore, and provide a .env.example with placeholder values so collaborators know what to configure. For deployment, use your hosting provider's environment variables or a dedicated secrets manager. For CI/CD, store credentials in GitHub Actions Secrets and grant workflows only the permissions they actually need.

I'd also recommend enabling Secret Scanning and Push Protection where available. Secret scanning helps identify exposed credentials, while push protection can block supported secrets before they reach the repository. These tools are useful safeguards, but they don't detect every possible secret, so code reviews and careful access management still matter.

One important point: if a real key or password has already been pushed, deleting it from the latest commit isn't enough. Revoke or rotate the credential immediately, then clean up the repository history if necessary. Also, never expose server-side API keys in frontend code, since users can inspect browser-delivered JavaScript.

Useful references: [GitHub secret security](https://docs.github.com/en/code-security/concepts/secret-security), [Push Protection](https://docs.github.com/en/code-security/concepts/secret-security/push-protection), and [Using secrets in GitHub Actions](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). A related community discussion is [How to safely store API keys in a GitHub project?](https://github.com/orgs/community/discussions/188310).

[Ava-91]

One important principle is that secrets management should be treated as a lifecycle, not just a matter of adding .env to .gitignore.

I'd recommend the following practices:

• Separate secrets by environment. Use local environment variables for development, your hosting provider's secret configuration for deployment, and GitHub Actions Secrets for CI/CD credentials. Avoid sharing production credentials with local development or test environments.
• Commit configuration templates, never credentials. Keep .env files out of version control and provide a .env.example containing variable names and safe placeholders so contributors can configure their environments consistently.
• Apply least privilege. Give each token only the permissions it needs, use short-lived credentials where supported, and restrict GitHub Actions' GITHUB_TOKEN permissions. Avoid exposing secrets to workflows triggered by untrusted pull requests.
• Enable preventive and detective controls. Use GitHub Secret Scanning and Push Protection where available, alongside code reviews and automated checks. These controls reduce risk but cannot guarantee that every secret will be detected.
• Keep client and server responsibilities separate. Anything shipped to a browser should be considered publicly accessible. Frontend environment variables are not automatically secret; private API keys and database credentials must remain on the server, with sensitive operations handled through an appropriately secured backend.
• Plan for incidents. If a credential is exposed, revoke or rotate it immediately, investigate potential misuse, and remove it from repository history when appropriate. Rewriting history alone does not invalidate a leaked credential.

Finally, document the required environment variables and the process for provisioning, rotating, and revoking them. This makes secure practices easier for contributors to follow instead of relying on everyone to remember them.

Useful references:

• [GitHub secret security](https://docs.github.com/en/code-security/concepts/secret-security)
• [Using secrets in GitHub Actions](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)

The goal isn't simply to prevent secrets from being committed; it's to minimize their exposure, limit the damage if one leaks, and make recovery straightforward.

[KPriyanshuCodes]

1. Catch secrets before they are committed
Add a pre-commit hook with a scanner such as gitleaks or detect-secrets. It blocks a key on your own machine, before push protection even runs.

2. If a secret was already pushed

• Revoke or rotate the key first. Anyone who cloned the repo earlier still has the old copy.
• Then remove it from history with git filter-repo (or BFG Repo-Cleaner) and force-push.
• To check old commits for a leaked key, run git log -p -S "API_KEY".

3. Hosting platforms
On Vercel, Netlify and similar services, set secrets in the project's environment variable settings, not in the repo. Don't use prefixes like NEXT_PUBLIC_ or VITE_ for private keys, because those values are sent to the browser.

4. Help collaborators
Commit a .env.example with placeholder values, so contributors know which variables to set without ever seeing real ones. Keep the real .env in .gitignore.

Combined with Secret Scanning and Push Protection, this covers prevention, detection and recovery.