Client-Side Web Crypto Key Storage Boundaries
CryptoKey objects can be stored in IndexedDB without exporting key material, but extractable:false does not stop XSS or account compromise.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
A Web Crypto CryptoKey can be serialized into browser storage; MDN describes IndexedDB as a common choice. Storage alone does not make key management safe: malicious same-origin code may still ask the key to perform an allowed operation. See MDN’s Web Crypto overview, CryptoKey.extractable, and WebKit’s cryptography guidance. The Web Cryptography specification source also defines the CryptoKey model.
*Metaphor for limiting key export; it does not show allowed cryptographic operations or an XSS scenario.*
Conceptual illustration, not a browser security test.
What CryptoKey and extractable mean
CryptoKey represents key material with algorithm, usages, type, and extractable properties. Setting extractable:false prevents exportKey or wrapKey from exporting the key. It does not prevent running code from requesting an allowed operation such as encryption or decryption, and it is not equivalent to encrypting the stored database. Limit the key’s usages to what the feature needs.
IndexedDB reduces one kind of exposure
CryptoKey is serializable through structured cloning and can be stored in IndexedDB and read back. A non-extractable key avoids exposing raw key bytes to application code during that flow. Other threats remain: compromised browser profiles, same-origin XSS, weak account recovery, and device backup or synchronization. Design key lifetime and account separation; do not treat browser storage as a secure vault by default.
Wrapping keys adds another dependency
If key material must move, wrapKey and unwrapKey can protect an exported key with a wrapping key. The design then depends on how that wrapping key is generated, stored, and recovered. Separate data-encryption and wrapping keys, review algorithm parameters, and document recovery. Composing low-level API calls does not by itself create a complete key-management system.
Start with the threat model
For browser-held secrets, decide whether the server may see the key, whether compromised same-device scripts are in scope, what logout should erase, and whether cross-device recovery is required. For example, after an XSS flaw, page script may be unable to export key bytes yet could still request an allowed decryption and send the result elsewhere; assess that path explicitly. extractable:false limits export, not permitted use. Design XSS defenses, CSP, session security, and storage cleanup together. For sensitive data, review the complete design before composing low-level Web Crypto primitives.
Design recovery and device changes
A CryptoKey in browser storage is not automatically backed up across browser-data deletion, profile resets, or device replacement. Do not assume account sync will move it safely. If you add a recovery key or server-side envelope encryption, model who controls that key and what a compromise would expose. If recovery is intentionally unsupported and logout should erase material, remove the IndexedDB record and related ciphertext according to a defined lifecycle.
Do not put raw keys, wrapping keys, or plaintext recovery material in developer tools or application logs. Review the encryption mode, nonce handling, authenticated encryption, and account-recovery path together rather than evaluating the storage API in isolation.