Responding to a leaked API key

If a k-ID API key has been exposed (committed to a repository, pasted into a public channel, written to a log, or shipped in client-side code), delete it and replace it as soon as possible. Anyone holding the key can call the k-ID API as your product until it's deleted.

Removing the key from your code or rewriting git history isn't enough on its own. Copies may already exist in forks, clones, caches, or CI logs. The only way to stop a leaked key from working is to delete it in Compliance Studio.

1. Identify the key

Work out which product and environment the key belongs to.

Current API keys start with their environment:

To find the key in Compliance Studio, open each candidate product, go to the Developer Settings tab, and switch between Test and Live. The API Keys section shows the first characters of every key; match them against the leaked value. Keys created before the current format are marked Legacy and show fewer characters.

2. Create a replacement key

A product can have more than one active key per environment, so you can usually replace a key without downtime.

1. On the same product's Developer Settings tab, with the same environment (Test or Live) selected, click Add API Key.
2. Enter a Description for the new key so you can tell it apart from the one you're replacing.
3. Copy the new key.
4. Update every place the old key is used: environment variables, your secrets manager, CI/CD variables, and any other services that call the k-ID API.
5. Deploy the change and confirm your integration is working with the new key.

3. Delete the leaked key

1. On the Developer Settings tab, find the leaked key in the API Keys section.
2. Click the Delete (trash) icon next to it, then click Confirm.

Deletion takes effect immediately. Requests using the deleted key are rejected with 401 Unauthorized, and a deleted key can't be restored.

4. Remove the key from where it leaked

Once the key is deleted it can't be used, but you should still clean up the exposure:

• Source control: Remove the key from your code and move it into an environment variable or secrets manager. If you want to remove it from your repository's history as well, see GitHub's guide to removing sensitive data from a repository.
• Client-side code: If the key shipped in a web page, mobile app, or game client, move every k-ID API call that uses it to your server. API keys must never reach end users' devices. See Security recommendations.
• Logs and messages: Delete or redact the key from logs, tickets, chat messages, and documents where it appeared.

5. Check for unexpected activity

• On the product's History tab, review the Activity section for API Key Added, API Key Edited, and API Key Removed entries you don't recognize, and check who made each change. See Version history and rollback.
• Review your own server logs and the sessions and verifications your product received while the key was exposed for anything you don't expect.

If you believe the key was misused, or you need help with any of these steps, contact support@k-id.com or your k-ID account manager. Include the product name, the environment, and roughly when and where the key was exposed. Don't include the key itself.

Preventing leaks

• Keep API keys on your server only, in environment variables or a secrets manager.
• Never commit keys to source control. Add files that hold secrets, such as .env, to your .gitignore.
• Give each service or deployment stage its own key, with a Description that says where it's used, so you can delete one key without affecting the others.
• Turn on GitHub secret scanning and push protection for your repositories.

For more on managing keys, see Developer settings.