SaaS API key security: create, store, rotate and revoke credentials
Protect customer API keys with scoped permissions, safe display and storage, planned rotation, rapid revocation and a clear incident response path.
In this guide
How should a SaaS product issue API keys?
An API key is a credential: anyone who obtains it may be able to act with its permissions. Treat it like a password or other secret, and design its lifecycle before shipping a key-generation screen. OWASP recommends central secret management, least privilege, auditing and a rotation process suited to the secret's exposure and use.
Create a high-entropy secret and show it once
Generate keys with a cryptographically secure random source and enough entropy to resist guessing. Show the secret only at creation, explain that it cannot be retrieved later and offer a copy action that does not send it to analytics or logs. Use a non-secret prefix or identifier so a customer can recognise a key without revealing its value.
Limit key permissions, tenant and environment
Give each key only the API operations it needs, constrain it to the issuing tenant and distinguish test from production credentials. Consider per-integration keys rather than one shared company-wide key. Where network restrictions or expiry suit the integration, make those controls explicit and test their effect on legitimate jobs.
Store a verifier or encrypted secret according to use
If your service only needs to verify a presented customer key, store a one-way verifier and compare safely; do not keep a retrievable copy without a reason. If your service must later present a credential to another provider, encrypt it in a managed secret store and control decryption access. Keep secrets out of source control, browser storage, URLs and support tickets.
| Key ID / owner | Tenant and environment | Scopes and purpose | Created / expiry / last used | Rotation and revocation owner |
|---|---|---|---|---|
What is a safe API key rotation process?
Prepare a replacement before disabling the current key
Create a new scoped credential, deliver it through the normal secure flow and give the customer a short, defined overlap window if the integration needs time to switch. Track use of the old and new key separately. Do not leave both active indefinitely; make the final revocation date visible.
Make revocation quick and predictable
A user with the right authority should be able to disable a compromised or retired key without deleting the customer account. Define how quickly the change takes effect across caches, workers and regional services, then test that no hidden copy or long-lived session keeps the key usable.
Choose rotation timing from risk and exposure
Use the credential's privilege, environment, lifetime, storage path, vendor guidance and incident history to set a rotation policy. A fixed schedule is not a substitute for immediate revocation after exposure. Automate rotation when the integration safely supports it, and monitor failures during a planned change.
How do you detect and respond to a leaked API key?
Keep the key value out of telemetry
Redact authorization headers and request bodies before logging, tracing or error reporting. Search build output, repositories, tickets and shared documents for accidental exposures using approved secret-scanning tools. Store only the key identifier or a safe fingerprint in logs so responders can identify the affected credential.
Revoke first, then investigate the affected activity
Disable a confirmed exposed key promptly, notify its owner through a trusted route and issue a replacement only after the integration is ready. Review the key's recent activity, tenant scope, data access and downstream actions. Preserve relevant audit evidence under the incident process without copying the secret into the report.
Give customers a clear key-management view
Show a stable key name or prefix, scopes, environment, creation time, last-used time and status. Warn before revocation if known jobs may stop, but keep emergency revocation available. Record creation, scope changes and revocation as audit events visible to authorised workspace administrators.
SaaS API key security questions
Should a customer API key be stored as plain text?
No, unless there is a narrowly justified need to retrieve it later; in that case use encryption and tightly controlled secret management. If the service only validates a submitted key, a one-way verifier is generally a safer design. Never include the secret in logs or source code.
How often should API keys be rotated?
Set a policy based on privilege, exposure and how the key is used. Revoke immediately when compromise is suspected. For scheduled rotation, overlap old and replacement credentials only for a limited migration window and verify the old key is no longer accepted.
Can one API key be shared across a whole team?
Avoid broad shared credentials where per-user or per-integration credentials are practical. Separate keys improve attribution, scope and revocation: removing one integration does not require replacing every other workflow's secret.
What should a customer do if a key appears in a public repository?
Revoke it immediately in the product, create a replacement, update the integration securely and inspect activity from the exposure window. Deleting the visible text does not make the old credential safe because it may already have been copied.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Cheat Sheet: Secrets ManagementOWASP Foundation
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- OWASP Cheat Sheet: LoggingOWASP Foundation