Web Crypto API (SubtleCrypto)

The Web Crypto API provides browser-native cryptographic primitives for hashing, key generation, encryption, decryption, signing, verification, and secure random values. Frontend engineers commonly access asynchronous cryptographic operations through `crypto.subtle` and obtain random bytes with `crypto.getRandomValues()`.

The API is exposed through the global `crypto` object. Its `subtle` property provides the `SubtleCrypto` interface, whose methods return Promises for operations such as `digest()`, `generateKey()`, `encrypt()`, `decrypt()`, `sign()`, and `verify()`.

`crypto.getRandomValues()` fills an integer typed array with cryptographically strong random values. This is appropriate for generating unpredictable nonces, salts, and other random material, subject to the requirements of the specific cryptographic protocol.

Web Crypto supports several families of algorithms, including SHA-2 hashing, AES encryption, RSA and elliptic-curve operations, and newer algorithms depending on browser support. Algorithm parameters are supplied explicitly, so the exact algorithm and options should be chosen according to the protocol being implemented rather than treating the API as a generic encryption wrapper.

A `CryptoKey` represents key material and carries properties such as its algorithm, intended usages, and whether it is extractable. Keeping keys non-extractable when possible can reduce accidental exposure, although Web Crypto does not by itself make an application's overall key-management design secure.

Web Crypto is generally intended for secure contexts such as HTTPS. It provides low-level primitives, not a complete application security protocol: developers still need to handle authentication, key distribution, storage, nonce management, error handling, and protocol design correctly.

Key points

• Use `crypto.subtle` for browser cryptographic operations and `crypto.getRandomValues()` for cryptographically secure random values.
• Most `SubtleCrypto` operations are asynchronous and return Promises.
• `CryptoKey` objects encode algorithm and usage constraints and can be marked non-extractable.
• Use authenticated encryption such as AES-GCM when confidentiality and integrity are both required.
• Web Crypto supplies primitives; it does not automatically solve application-level key management or protocol design.

Interview questions

What is the Web Crypto API used for?

It is a browser API for performing cryptographic operations without implementing the cryptographic algorithms in application JavaScript. Its main interfaces expose secure randomness and operations such as hashing, encryption, decryption, signing, verification, and key generation. The `crypto.subtle` interface handles many of these operations asynchronously. It is a primitive-level API, so developers still have to design the surrounding security protocol correctly.

How would you generate secure random bytes in the browser?

I would use `crypto.getRandomValues()` with an integer typed array such as `Uint8Array`. The API fills the array using a cryptographically suitable source of randomness provided by the browser environment. I would not substitute `Math.random()` because it is not intended as a cryptographic random-number generator. The number of bytes should be selected according to the security protocol that consumes them.

What is a `CryptoKey`, and why does extractability matter?

A `CryptoKey` represents cryptographic key material together with metadata describing its algorithm and permitted operations. Its usages can restrict whether it is used for purposes such as encryption, decryption, signing, or verification. An extractable key may be exported into another representation, whereas a non-extractable key cannot normally be exported through the Web Crypto key-export mechanisms. Using non-extractable keys where export is unnecessary can reduce opportunities for accidental key disclosure, although it does not eliminate all application security risks.

Why is AES-GCM commonly preferred over using AES-CBC alone for application encryption?

AES-GCM provides authenticated encryption, meaning it protects confidentiality while also producing an authentication tag that detects tampering. AES-CBC by itself provides confidentiality but does not authenticate the ciphertext. With GCM, nonce uniqueness for a given key is a critical requirement, so nonce generation and storage must be designed carefully. The choice should still follow the protocol's requirements rather than assuming that any AES mode is interchangeable.

What security responsibilities remain when using Web Crypto?

Web Crypto implements cryptographic primitives, but the application still has to define a secure protocol around them. That includes choosing appropriate algorithms, managing keys and their lifetimes, preventing nonce reuse, authenticating peers where necessary, and protecting sensitive data from application-level vulnerabilities. Secure transport and browser isolation also matter because correctly encrypted data does not compensate for compromised application logic or leaked keys. I would therefore treat Web Crypto as a building block rather than a complete security architecture.