example-petstore.com

Example domain · Not a live service · Browser visits show this page · API requests get 410 Gone

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

  1. Revoke the key, token or password at the service that issued it. Deleting it from your code is not enough.
  2. Issue a new one and store it in configuration or a secrets manager, not in code or version control.
  3. Correct the address in your code first, so the new credential only goes to the real service.
  4. Review the service’s access logs or audit log for activity you do not recognise since the first request to the example domain.
  5. If real card details were sent, contact the card issuer.

Revoke by provider

ProviderWhat to revokeWhere
GitHubPersonal access tokensManaging your personal access tokens
Google CloudAPI keys, service account keysManage API keys · Respond to compromised credentials
AWSIAM access keysManage access keys for IAM users
StripeSecret and restricted keysAPI keys
SlackBot and user tokensauth.revoke
AnthropicAPI keysAPI key best practices
OpenAIAPI keysBest practices for API key safety
Other servicesAny key, token or passwordThe 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.

Committed the key to Git as well? Removing a secret from Git history

Sources