Un sitio moderno puede trabajar con cámara y micrófono, dispositivos USB y Bluetooth, HID, puertos serie, archivos locales, el portapapeles y GPU. El sitio no obtiene acceso directo a todo el equipo: entre el código web y el hardware permanecen las API del navegador, el sistema operativo, los controladores y las reglas de permisos.
En septiembre de 2026 el investigador Auberon López mostró Deathray: una página mediante WebGPU podía llevar un Mac a kernel panic y reinicio. Apple no reconoció este fallo como una vulnerabilidad de seguridad, ya que no proporcionaba acceso a datos ni privilegios adicionales, aunque el reinicio forzado tras abrir la página claramente excede las expectativas habituales sobre un navegador.
Para la cámara, USB, Bluetooth, HID, puertos serie y archivos se aplica el modelo de «solicitar y elegir»: el sitio pide acceso y el usuario permite una capacidad concreta o selecciona un dispositivo. WebGPU funciona de otra manera. La página obtiene acceso de cálculo a la GPU sin una ventana separada de «permitir tarjeta gráfica», de forma similar a la capacidad de ejecutar JavaScript o WebAssembly.
Cómo obtiene un sitio acceso a la cámara, USB, Bluetooth, puertos y archivos
Para la mayoría de las interfaces de hardware, el navegador concede el derecho a un recurso concreto y no acceso general a toda la categoría de dispositivos. Por eso normalmente un sitio no puede inspeccionar silenciosamente todo el equipo USB, abrir cualquier carpeta o conectarse a cualquier dispositivo Bluetooth.
| Funcionalidad | Cómo obtiene acceso el sitio | Qué puede conservarse |
|---|---|---|
| Cámara y micrófono | El navegador muestra una solicitud mediante getUserMedia(). | El permiso puede ser puntual o conservarse para el sitio. |
| USB | WebUSB abre una ventana para elegir el dispositivo compatible. | El sitio puede volver a ver un dispositivo previamente autorizado mientras el permiso no sea revocado. |
| Bluetooth | Web Bluetooth requiere la acción del usuario y la selección del dispositivo adecuado. | El navegador puede recordar el dispositivo y los servicios autorizados. |
| HID | WebHID ofrece elegir un dispositivo. | Se pueden recuperar dispositivos autorizados anteriormente. El navegador restringe las interfaces HID sensibles. |
| Puerto serie | Web Serial abre la selección del puerto. | El sitio puede obtener puertos autorizados anteriormente mediante getPorts(). |
| Archivos locales | File System Access API permite elegir un archivo o una carpeta. | El navegador puede recordar el objeto seleccionado y el permiso de acceso. |
| Portapapeles | Clipboard API permite leer y escribir datos con las restricciones del navegador. | La lectura normalmente requiere una acción del usuario, permiso u otra confirmación. Las reglas concretas dependen del navegador. |
| GPU | WebGPU proporciona un adaptador lógico de GPU a través del navegador sin la ventana típica de permiso. | Aquí no existe un permiso permanente como en el modelo de cámara o USB. |
Incluso después de conceder permisos, la aplicación web funciona a través de la interfaz del navegador y no obtiene acceso directo universal al hardware. La API File System Access, por ejemplo, entrega un objeto del archivo o directorio seleccionado, no todo el disco. WebUSB, WebHID y Web Serial limitan su funcionamiento al hardware para el que el sitio obtuvo permiso.
Por qué los permisos del navegador no protegen contra todo
La ventana de permiso responde, ante todo, a si el sitio puede acceder al recurso. Esa ventana no garantiza que cada comando enviado tras conceder el permiso sea seguro. Si la aplicación web obtiene acceso a un programador, a un puerto serie o a un dispositivo HID no estándar, las consecuencias dependen también del protocolo y de las capacidades del propio hardware.
WebGPU muestra otra variante del mismo problema. El usuario no elige la tarjeta gráfica física; el navegador asigna a la página una interfaz limitada. La especificación de WebGPU prevé comprobaciones de comandos, aislamiento de memoria y restricciones sobre la información del hardware, pero el navegador sigue delegando el trabajo a las capas inferiores del sistema gráfico. Un error en el controlador, en el firmware o en el mecanismo para detener un shader bloqueado puede convertir una operación válida del navegador en un fallo del sistema.
También existe el problema de la fatiga por permisos. Según datos de Chrome, los usuarios ignoraban o cerraban alrededor del 85% de las solicitudes de notificaciones. Cuanto más a menudo el navegador plantea estas preguntas, mayor la probabilidad de que la persona pulse «permitir» sin leer el texto. Por eso Chrome introdujo solicitudes menos intrusivas y permisos puntuales para algunas capacidades sensibles.
La regla práctica es sencilla. La solicitud debe corresponder a la acción que el usuario acaba de iniciar. Una videollamada requiere cámara; una página de configuración del hardware puede solicitar USB o Bluetooth. Si un sitio normal solicita de pronto un puerto serie, una carpeta del disco o un dispositivo desconocido, es más seguro denegar y averiguar la razón.
El mero hecho de que aparezca una ventana del sistema no demuestra que el sitio sea de confianza. El navegador solo indica qué capacidad quiere obtener la página.
Preguntas y respuestas
¿Puede un sitio ver todos los dispositivos USB del ordenador?
Normalmente no. WebUSB propone al usuario elegir el dispositivo adecuado. El sitio puede volver a acceder al equipo previamente autorizado mientras el permiso se conserve.
¿Se necesita permiso del navegador para WebGPU?
Normalmente no hay una solicitud específica de «permitir GPU». El navegador proporciona a la página la interfaz limitada WebGPU y comprueba los comandos antes de pasarlos al sistema gráfico.
¿Por qué Apple no considera a Deathray un problema de seguridad?
Apple clasificó el resultado como un fallo, bloqueo o pérdida recuperable de datos sin escalado de privilegios ni filtración de información. López indica que muchos expertos en seguridad que entrevistó coinciden con esa clasificación técnica, mientras que los usuarios habituales tienden a percibir un reinicio forzado como un problema de seguridad.
¿Puede un sitio leer todo el disco a través de la API File System Access?
No. El usuario elige un archivo o un directorio concreto, y el navegador ofrece al sitio un objeto para trabajar con el recurso seleccionado.
¿Se conservan los permisos después de cerrar el navegador?
Depende de la API, del navegador y de la elección del usuario. Algunos permisos son puntuales; otros pueden mantenerse hasta su revocación manual.
Conclusión
El navegador dejó de ser una aplicación solo para mostrar páginas. Las aplicaciones web trabajan con la cámara, archivos, USB, Bluetooth, dispositivos HID, puertos serie y la GPU. Parte de las capacidades requieren la selección explícita del recurso, mientras que WebGPU proporciona una interfaz de cálculo sin un permiso separado para la tarjeta gráfica física.
Deathray muestra el límite de ese modelo. El navegador puede no permitir que la página lea archivos ajenos o ejecute código de sistema arbitrario, pero un error por debajo del navegador puede igualmente afectar a todo el equipo. El debate sobre la clasificación de Deathray revela otra frontera: los especialistas pueden considerar un fallo del sistema como una denegación de servicio sin violar el modelo de seguridad, mientras que el usuario percibe el reinicio forzado al abrir un enlace como una ruptura de la confianza en el navegador.
El material está destinado al estudio seguro de las tecnologías web y a la protección de los propios dispositivos. No ejecute páginas que puedan causar denegaciones de servicio en ordenadores ajenos sin el permiso del propietario. Cumpla la legislación de la Federación Rusa y las normas de los propietarios de los sistemas de información.
