La API de criptografía web proporciona una interfaz estandarizada para realizar operaciones criptográficas en aplicaciones web. Ofrece generación segura de números aleatorios, hash, firma y capacidades de cifrado. Aunque es más segura que la implementación de la criptografía en JavaScript, la gestión adecuada de las claves y la selección de algoritmos siguen siendo fundamentales.
La Web Crypto API es una interfaz nativa del navegador, expuesta a través de window.crypto y crypto.subtle, para realizar operaciones criptográficas en JavaScript. Cubre valores aleatorios criptográficamente fuertes mediante getRandomValues, además de hashing, HMAC, cifrado simétrico y asimétrico, firmas digitales y derivación de claves a través del objeto SubtleCrypto. Las primitivas están implementadas en el motor del navegador en código nativo en lugar de en script, lo que es más rápido y menos propenso a errores que una criptografía artesanal en JavaScript. Las claves se representan como objetos CryptoKey que pueden marcarse como no extraíbles, de modo que el material de clave en bruto nunca tiene que exponerse al JavaScript que lo rodea. La mayor parte de la API está restringida a contextos seguros, es decir, páginas servidas por HTTPS o localhost.
Usar una implementación nativa contrastada elimina clases enteras de errores que aquejan a la criptografía personalizada en JavaScript, como las fuentes de aleatoriedad débiles, las fugas por temporización y el ensamblaje incorrecto de algoritmos. Los objetos CryptoKey no extraíbles hacen que ni siquiera el script que se ejecuta en la página pueda leer los bytes subyacentes, lo que limita lo que un compromiso puede robar. Sin embargo, la API no hace segura una aplicación por sí sola. Malas elecciones de algoritmo, vectores de inicialización reutilizados, claves codificadas o mal almacenadas y salidas mal gestionadas la debilitan. Y algo crucial: cualquier criptografía realizada en el navegador sigue ejecutándose en un entorno que un atacante puede controlar: un fallo de cross-site scripting puede llamar a la misma API, usar las claves disponibles y cifrar o firmar en nombre del atacante.
Elige algoritmos y parámetros actuales y bien comprendidos, genera claves e IV con getRandomValues, y nunca envíes claves secretas en el código del cliente. Marca las claves como no extraíbles siempre que el flujo de trabajo lo permita, y apóyate en las funciones de derivación de claves de la API en lugar de inventar la tuya. Como la criptografía del lado del navegador solo protege los datos en la medida en que se pueda confiar en el cliente, mantén la página circundante libre de script inyectado: aplica una Content Security Policy estricta y sanea las entradas para cerrar el XSS. La Web Crypto API es una primitiva neutral de la plataforma web, así que cside no participa directamente en su funcionamiento; la disciplina defensiva relevante es el desarrollo seguro estándar y mantener el JavaScript de terceros no confiable fuera de la página.
Por lo general, sí. Las primitivas nativas son más rápidas, las mantienen los proveedores de navegadores y evitan muchos escollos de implementación de la criptografía en JavaScript puro, incluida la aleatoriedad débil. Las bibliotecas siguen teniendo cabida para algoritmos que la API no cubre, pero para el hashing, el cifrado y la firma estándar la API integrada es la opción más segura por defecto.
No. Se ejecuta en el navegador, un entorno que la máquina del usuario y cualquier script inyectado pueden influir. Endurece las primitivas, pero un fallo de cross-site scripting puede invocar la misma API y usar indebidamente las claves disponibles. Complementa, no reemplaza, el cifrado en tránsito y los controles del lado del servidor.
We answer client-side security questions every day. Bring yours.