1. Revoke first
Assume a committed credential may have been copied. Use the provider dashboard or API to revoke it, then create a replacement with the minimum permissions necessary.
2. Investigate possible use
Review provider audit logs, billing activity, authentication events and unusual traffic from the earliest possible exposure time. Preserve evidence if abuse is suspected.
3. Fix the application
Read the replacement from a server-side environment variable or secret manager. Never expose a server credential in browser JavaScript. Add .env files to .gitignore and commit only a placeholder example.
4. Consider cleaning history
Repository history can be rewritten to remove a secret, but rewriting affects collaborators and does not revoke copies already cloned or cached. Follow the hosting provider's current sensitive-data removal process and coordinate the change carefully.
5. Add prevention
Add secret scanning, pre-commit checks, least-privilege credentials and a written rotation procedure. Re-scan before the next release.
Frequently asked questions
Is making the repository private enough?
No. People, integrations, caches or clones may already have the credential. Rotate it.
Can I reuse the same key after deleting the commit?
No. Use a newly issued credential and treat the old one as compromised.