Guide · Security
Leaked credentials: what to do now
If your code sent a key, token, password or session cookie to example-petstore.com or example-commerce-host.com, it reached a server you do not control. Treat it as exposed and replace it. Only the service that issued it can revoke it.
Do this now
- Revoke the key, token or password at the service that issued it. Deleting it from your code is not enough.
- Issue a new one and store it in configuration or a secrets manager, not in code or version control.
- Correct the address in your code first, so the new credential only goes to the real service.
- Review the service’s access logs or audit log for activity you do not recognise since the first request to the example domain.
- If real card details were sent, contact the card issuer.
Revoke by provider
| Provider | What to revoke | Where |
|---|---|---|
| GitHub | Personal access tokens | Managing your personal access tokens |
| Google Cloud | API keys, service account keys | Manage API keys · Respond to compromised credentials |
| AWS | IAM access keys | Manage access keys for IAM users |
| Stripe | Secret and restricted keys | API keys |
| Slack | Bot and user tokens | auth.revoke |
| Anthropic | API keys | API key best practices |
| OpenAI | API keys | Best practices for API key safety |
| Other services | Any key, token or password | The security or API settings of that service; search its documentation for “revoke” or “rotate”. |
Afterwards
- Remove the old credential from repositories, logs and configuration history. Rewriting history does not make it safe again; revoking does.
- Turn on secret scanning in your repositories, for example GitHub secret scanning, so leaked keys are reported early.
- Add a check that stops example addresses from reaching production. See configuring API clients and SDKs.
Sources
- Secrets Management Cheat Sheet OWASP
- Secret scanning GitHub Docs