API key security and leak response

Keep developer API keys on trusted servers and revoke an exposed key before relying on removal of the public copy.

What you will learn

• Use the three registered management scopes.
• Rotate without assuming a grace overlap.
• Investigate and recover from confirmed or suspected exposure.

Prerequisites

• Read authentication.
• Have authorized access to your workspace's API keys, API logs and audit logs.
• Do not paste secrets into support messages or documentation feedback.

Prevent exposure

Use one named key per service, product and environment where practical. Store it in backend secret configuration and give its service account the minimum access. Sandbox and Live credentials must not be interchangeable.

An arbitrary scope string does not add a permission. A read-only integration does not need licenses:write. A desktop app uses the public App ID and installation token, never an lmp_ key.

Scan release packages, repository changes, CI logs, screenshots and crash reports. Do not put credentials in URLs, shell history or analytics. Redact Authorization and raw customer payloads from your own logs.

Immediate containment

1. Identify the affected key in API keys by its display prefix, product, environment and name.
2. Revoke it immediately if exposure is suspected; do not wait for evidence of misuse.
3. If using Rotate, securely copy the new secret once and deploy it to the intended backend.
4. Confirm the old key no longer works and the replacement performs only its intended operation.
5. Remove the exposed copy from active configuration and distribution channels.

Expected result: the old credential cannot authenticate. Rotation revokes the old key immediately; there is no automatic overlap. Coordinate deployment or accept a short controlled interruption.

Do not test a leaked credential against tenants you do not own. Deleting a public message or commit does not revoke the credential and cannot guarantee nobody copied it.

Investigation

1. Record the earliest possible exposure time and affected product/environment.
2. Review API logs for method, endpoint, HTTP status, time and request_id.
3. Correlate request IDs and affected resource IDs with audit logs and your own backend logs.
4. Identify actual license creation, state changes or device resets during the window.
5. Preserve only necessary investigation records in restricted storage.

Expected result: distinguish confirmed actions from suspicions. The API log does not retain request bodies or Authorization tokens; missing payload details are not proof no incident occurred. Retention varies by plan and cleanup scheduling.

Recover affected licenses

1. List only the licenses affected by confirmed unauthorized actions.
2. Suspend or revoke those requiring containment under your policy.
3. Review unintended device resets and ask legitimate customers to reactivate when necessary.
4. Reissue or restore access only after confirming the intended customer and product.
5. Validate the repaired state in Sandbox or an explicitly authorized real incident workflow.
6. Monitor new failures and unexpected management requests.

Expected result: recovery is targeted. Do not revoke every customer's license without evaluating impact. Revoked activation tokens do not automatically revive when a license is restored.

Notify and improve

Inform affected parties with confirmed facts, impact, steps taken and support options. Avoid speculative accusations or disclosing other customers' data. Assess personal-data breach obligations with qualified advice; this playbook is not a legal determination.

Restrict new keys, repair the leaking pipeline, rotate other actually exposed credentials and record the incident. A management key, activation token, webhook secret and signing private key are different credentials with different remediation. Suspected signing-key exposure must be escalated to KDPika security contact.

Expected result

The leaked key is invalid, replacement scope is minimal, affected actions are identified and recovery is documented.

Common mistakes

• Removing a public secret without revoking it.
• Assuming rotated credentials overlap safely.
• Claiming API logs contain bodies that the logger intentionally does not capture.

Security notes

Keep the investigation private and redact credentials. Review operational access to server configuration and backups; cryptographic hashing at rest does not make an exposed usable token harmless.

Troubleshooting

Next steps

Read signed responses and the threat model, then validate your own integration in Sandbox.

Related

• Verification examples
• Offline mode
• Security and disclosure