Why we’re doubling down on API token security

Unleash 8.3 introduces hashed API tokens so that newly created backend, frontend, personal access, and service account tokens are displayed only once and stored as hashes plus metadata rather than recoverable plaintext, reducing the risk that a database or backup exposure yields usable credentials. The change responds to increasing credential-based attacks and recognizes that feature-flag tokens can grant access to release workflows, SDK configuration, automation pipelines, Edge instances, Terraform, and integrations. Secure tokens use a selector and a 32-byte random secret, allowing Unleash to locate a token record and verify a SHA-256 hash without retaining the full value; they remain compatible with existing SDKs and Edge deployments. Existing pre-8.3 tokens continue to work without a deprecation deadline but remain stored in full until deleted, so users are encouraged to rotate them by creating replacements, updating dependent integrations, and removing legacy tokens. Hashing protects tokens stored in the Unleash database but does not protect copies held in secrets managers, pipelines, Edge persistence stores, Terraform state, logs, or older backups, making secure storage, least-privilege access, and regular credential rotation still necessary.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.