Herramientas de desarrollo · UUID generador
Por qué crypto.randomUUID() falla en páginas HTTP: contextos seguros explicados
· Cómo funciona
uuid criptografía APIS del navegador
crypto.randomUUID funciona en localhost y en HTTPS, luego desaparece en un host de prueba HTTP simple. Esta publicación explica la regla de contexto seguro detrás de ese comportamiento y cómo generar un UUID de forma segura donde se aplica.
TypeError en la preparación, bien en cualquier otro lugar: el síntoma y la diferencia de entorno que lo causa
Un desarrollador verifica su trabajo en localhost:3000 y el generador UUID funciona perfectamente. Se despliegan en la preparación en http://staging. interno. ejemplo. com (HTTP simple en la LAN de la empresa) y el código arroja TypeError: crypto.randomUUID no es una función. El mismo código en producción en https://example. com funciona bien. La inconsistencia es desconcertante hasta que leen los documentos de MDN: crypto.randomUUID está restringido a contextos seguros. Un contexto seguro es HTTPS o localhost; un origen HTTP simple en una LAN no es seguro según la regla del navegador, incluso si la red es privada. La solución es utilizar crypto.getRandomValues con operaciones de bits manuales o actualizar el servidor provisional a HTTPS. La regla de contexto seguro se introdujo para evitar que las API confidenciales se filtren a conexiones no cifradas.
Qué es un contexto seguro: la regla del navegador que reserva ciertas API para orígenes HTTPS y para localhost
Una página a través de HTTP simple puede ser interceptada por un atacante de red; exponer las API criptográficas a dicha página haría posible que un atacante generara identificadores utilizando una API comprometida. HTTPS cifra la página y todas las comunicaciones API para que un atacante en la red no pueda interceptar ni modificar el código. Localhost se trata como inherentemente seguro porque sólo existe en la máquina local y no puede ser interceptado a través de la red. Cualquier otro origen HTTP (una dirección LAN, un dominio público sin HTTPS, un proxy inverso que reenvía a HTTP) no es seguro por definición. La Web Crypto API se divide en dos funciones: crypto.randomUUID, restringida a contextos seguros, y crypto.getRandomValues, disponible tanto en contextos seguros como no seguros. Ambos utilizan el mismo sistema operativo CSPRNG.
Qué partes de Web Crypto están cerradas: crypto.randomUUID y crypto.subtle requieren un contexto seguro, mientras que crypto.getRandomValues no.
La diferencia es que getRandomValues no oculta el hecho de que estás utilizando criptografía; una página que lo utiliza debe solicitar explícitamente bytes aleatorios. La función randomUUID es una comodidad que también impone un contexto seguro. Si su aplicación necesita generar UUID en una página no segura, debe usar getRandomValues y configurar manualmente la versión y los bits de variante. RFC 9562 especifica las operaciones de bits: establezca el byte 6 en (byte6 y 0x0f) | 0x40 para la versión 4 y byte 8 a (byte8 y 0x3f) | 0x80 para la variante RFC. La biblioteca ToolAcre hace exactamente esto como alternativa cuando randomUUID no está disponible. Reproducir el error: servir una página simple desde un origen HTTP simple que no se trata como potencialmente confiable. Compruebe si randomUUID está expuesto y luego compare getRandomValues, que la referencia de Web Crypto permite en contextos inseguros.
Creación de una v4 UUID a partir de getRandomValues: el recurso alternativo de enmascaramiento y formato que lo mantiene en CSPRNG cuando falta randomUUID
El mismo código en un archivo servido a través de HTTPS puede exponer UUID aleatorio. Si la producción informa que "randomUUID no es una función", primero inspeccione si el origen es un contexto seguro, luego verifique la compatibilidad del navegador y si otro script reemplazó el objeto criptográfico. La solución puede ser HTTPS o una implementación getRandomValues que establezca los bits UUID explícitamente. Un polyfill Math.random no es un recurso alternativo equivalente: reproduce la forma mientras elimina el contrato de fuente criptográfica. Las pruebas que afirman solo guiones y dígitos de versión omitirán esa sustitución, así que revise la ruta de origen así como la cadena resultante.
Ejemplo resuelto: reproducir el error en un origen http:// y confirmar la solución
Pero el identificador ahora es predecible. Un atacante que capture algunos UUID de su sistema puede predecir el siguiente. Si una aplicación trata erróneamente dicho identificador como una credencial de portador, la previsibilidad se convierte en una falla de autorización en lugar de un defecto cosmético. La estrategia correcta es actualizar el servidor a HTTPS (siempre es el movimiento correcto para cualquier página con autenticación o datos confidenciales) o usar getRandomValues con operaciones de bits explícitas (que requiere más código pero es criptográficamente sólida). El navegador impone el contexto seguro; no se puede solucionar con variables de configuración o de entorno. El generador ToolAcre se implementa a través de HTTPS, por lo que crypto.randomUUID está disponible. Cuando genera un UUID en la herramienta, utiliza randomUUID (si pasa la verificación de contexto seguro) o getRandomValues con operaciones de bits (si está en HTTP simple, aunque esto es raro).
Por qué no deberías realizar el polyfill con Math.random: el tentador atajo y el coste de seguridad que conlleva
Ninguna ruta vuelve a Math.random. Si está creando su propio generador UUID y apunta a orígenes no seguros, use getRandomValues y realice las operaciones de bits usted mismo. Pruebe tanto en HTTPS como en localhost para confirmar que el UUID aleatorio funciona, luego pruebe en un origen http:// para confirmar que su respaldo getRandomValues es correcto. Comprender la restricción del contexto seguro le ayuda a diseñar estrategias de implementación. Si su aplicación debe ejecutarse en una LAN privada sin HTTPS (infraestructura heredada, sistemas integrados), el recurso alternativo getRandomValues es su camino a seguir. Si tiene la opción, actualice a HTTPS en todas partes; es gratis con Let's Encrypt y la inversión se amortiza en seguridad en toda la aplicación. El desarrollo en localhost no tiene restricciones, así que pruebe su generador UUID en localhost y en la prueba HTTPS antes de implementarlo en producción. La producción siempre debe ser HTTPS.
Lo que esto no cubre: tiempos de ejecución de servidores como Node.js y Deno, que exponen la API sin una regla de contexto seguro
La restricción no es un error ni una molestia; es una característica de seguridad que previene accidentes y te obliga a pensar en el cifrado. El patrón más amplio es que las API de criptografía web están controladas por un contexto seguro. crypto.getRandomValues, cripto. sutil. cifrar, cifrar. sutil. generateKey y todas las demás operaciones confidenciales requieren HTTPS o localhost. No hay excepción, ni anulación, ni forma de desactivar la verificación. Una sola página insegura rompe las garantías de seguridad para tus usuarios. Incluso si tiene cuidado de utilizar API criptográficas solo en determinadas páginas, un error (o una dependencia que incluya un generador UUID) puede filtrar la generación de aleatoriedad a una página no cifrada. El generador ToolAcre aplica esto a nivel de código: si randomUUID no está disponible (contexto no seguro), utiliza getRandomValues, que está disponible pero alerta a cualquier revisor de código que está sucediendo algo inusual.
Conclusión: corrija el origen, no el generador: ToolAcre se sirve a través de HTTPS, por lo que su generador se ejecuta en un contexto seguro por diseño
Mejor aún, se niega a generar un identificador si el contexto seguro realmente no está disponible (en entornos donde getRandomValues tampoco está disponible, lo cual es poco común pero posible en sistemas más antiguos o integrados). Migrar un sistema existente a HTTPS para admitir API de criptografía segura es un proyecto común. Comience con el origen donde se generan los UUID (su servidor de autenticación, backend de API o servicio de aplicación clave). Adquiera un certificado TLS (Let's Encrypt los proporciona de forma gratuita). Configure su servidor web para servir HTTPS de forma predeterminada y redirigir las solicitudes HTTP a HTTPS. Pruebe con varios navegadores y clientes API para asegurarse de que todo funcione. Luego, audite su código para detectar cualquier API criptográfica restante que pueda ser invocada en páginas no cifradas y corríjalas. El generador ToolAcre asume HTTPS; si lo estás usando, ya eres parte del camino hacia allí.