Keep keys server-side
Store secrets in a trusted server environment. Redact them from logs and rotate exposed credentials. Do not put a secret key in browser JavaScript.
Store secrets at the boundary
Call the verification service from a trusted server. Use your deployment’s secret store, restrict access to the application that needs the key, and avoid including credentials in client bundles or support screenshots.
Respond to exposure
Revoke or rotate an exposed key through the operational service, update the application secret, and investigate unexpected usage. Removing a key from the latest source commit does not remove it from earlier history.
Design least-privilege access
Where scoped keys are supported, separate development and production access. The actual key permissions, rotation mechanism, and header format must be taken from the production contract.
Before you enable this workflow
| Confirm | Why it matters |
|---|---|
| Production contract | Use documented fields, limits, and supported operations. |
| Failure policy | Decide what the application does when a check cannot complete. |
| Data boundaries | Keep credentials and customer data out of unnecessary logs. |