Riesgos de seguridad en los navegadores: por qué el navegador es el nuevo punto final

El navegador es el entorno en el que se mueve su plantilla. Es allí donde los empleados inician sesión en aplicaciones SaaS, introducen datos de clientes en herramientas de IA, descargan archivos confidenciales, colaboran con socios externos y acceden a sistemas internos mediante el inicio de sesión único (SSO). Sin embargo, la mayoría de las arquitecturas de seguridad siguen considerando el navegador como una aplicación más entre muchas otras en el terminal, sujeta a las mismas políticas genéricas de EDR que un lector de PDF o un cliente de mensajería. Esa brecha entre cómo se desarrolla realmente el trabajo y cómo se aplica la seguridad constituye actualmente el mayor punto ciego en la seguridad empresarial.

Los datos de inteligencia sobre amenazas del sector revelan que la gran mayoría de las intrusiones en 2024 no utilizaron malware, lo que significa que se basaron en credenciales legítimas, flujos de identidad fiables e integraciones autorizadas —actividades que se originan en el navegador y discurren a través de él—. Si su estrategia de seguridad se limita al agente del terminal, está defendiendo un perímetro que ya no se corresponde con la superficie de ataque.

La filtración de datos en 90 segundos: un escenario que su EDR nunca detecta

Imagínese una tarde de jueves en una empresa de servicios financieros de tamaño medio. Una analista sénior abre Salesforce en Chrome para extraer los datos trimestrales de ingresos por clientes con vistas a una revisión interna. Copia una tabla con 200 registros de clientes —nombres, valores de los contratos, fechas de renovación— y los pega en ChatGPT, pidiéndole que redacte un resumen para su reunión interfuncional. Satisfecha con el resultado, descarga el análisis generado por la IA en formato PDF y lo guarda en su OneDrive personal para poder revisarlo en su iPad durante el fin de semana.

Todo el proceso se desarrolló en el marco de una única sesión del navegador. El agente de punto final detectó que Chrome realizaba solicitudes HTTPS. El sistema DLP de red detectó tráfico cifrado dirigido a dominios autorizados. No se guardó ningún archivo en el disco local hasta la descarga final del PDF; en ese momento, los datos ya habían escapado al control de la organización en dos direcciones: hacia los servidores de la herramienta de IA y hacia una cuenta personal de almacenamiento en la nube.

No se trata de un caso aislado hipotético. Es la realidad cotidiana en aquellas organizaciones en las que el trabajo basado en el navegador ha superado a los controles de seguridad basados en el navegador. Los atacantes que utilizan la inteligencia artificial han incrementado drásticamente sus operaciones año tras año, y las intrusiones se producen ahora a través de identidades de confianza, aplicaciones SaaS e infraestructura en la nube. Cuando el navegador actúa como intermediario en casi todas las interacciones con los datos, y su infraestructura de seguridad carece de visibilidad sobre lo que ocurre dentro de la sesión del navegador, está operando a ciegas.

Por qué los enfoques más antiguos fracasan en el ámbito del navegador

La mayoría de las infraestructuras de seguridad empresarial se diseñaron para un mundo en el que las amenazas llegaban en forma de archivos, atravesaban la red y llegaban a los terminales. Esa arquitectura resultaba eficaz cuando el trabajo se realizaba en aplicaciones instaladas localmente y los datos se almacenaban en servidores de archivos. Tres cambios estructurales han desbaratado este modelo.

Los agentes de los terminales no pueden acceder al contenido de la sesión del navegador

Las herramientas EDR supervisan el comportamiento de los procesos, las operaciones de escritura en archivos y las llamadas al sistema. Consideran que Chrome o Edge son un único proceso, y no las 30 pestañas, las 5 aplicaciones SaaS y las 3 extensiones del navegador que se ejecutan en su interior. Cuando un empleado copia datos personales identificativos (PII) de un cliente desde una pestaña del CRM y los pega en una pestaña del asistente de IA, el agente del terminal no registra ninguna actividad sospechosa. No hay ningún archivo, ni malware, ni proceso anómalo: solo una operación del portapapeles entre dos contextos del navegador.

El DLP de red pierde visibilidad con el cifrado y el SaaS

El cifrado TLS y el paso al modelo SaaS hacen que los dispositivos DLP de red tradicionales detecten tráfico cifrado dirigido a dominios autorizados. No pueden distinguir entre un empleado que sube una presentación de marketing aprobada a SharePoint y otro que sube una lista de clientes a una cuenta personal de Dropbox; en ambos casos, se trata de solicitudes POST HTTPS dirigidas a servicios en la nube reconocidos. El informe DBIR 2025 de Verizon confirmó que las credenciales robadas fueron el vector de acceso inicial en el 22 % de las filtraciones, y que dichas credenciales casi siempre se introducen a través de un navegador.

Los cortafuegos basados en categorías de URL no tienen en cuenta los matices

Las pasarelas web seguras de generación anterior, que bloquean o permiten dominios completos, no pueden aplicar los controles granulares que exigen los flujos de trabajo modernos de los navegadores. Bloquear ChatGPT por completo aleja a los equipos orientados a la productividad. Permitir su uso no ofrece ningún control sobre los datos que los empleados introducen en él. El modelo binario de «permitir/bloquear» —diseñado para una época en la que «inseguro» significaba «dominio malicioso conocido»— es estructuralmente incapaz de regular el uso de las herramientas autorizadas. Comprender las diferencias entre las pasarelas web tradicionales y las de nueva generación es el primer paso para cerrar esta brecha.

Qué ha cambiado: el navegador se ha convertido en el sistema operativo para el trabajo

La convergencia de tres tendencias transformó el navegador, que pasó de ser un simple motor de renderizado a convertirse en el principal espacio de trabajo de la empresa —y en su superficie de ataque más expuesta—.

El modelo SaaS ha transformado la pila de aplicaciones

Hace cinco años, las aplicaciones esenciales de un trabajador del conocimiento típico incluían clientes de correo electrónico instalados localmente, paquetes ofimáticos y herramientas específicas de su sector. Hoy en día, ese mismo trabajador accede a Salesforce, Microsoft 365, Workday, ServiceNow, Slack y Jira exclusivamente a través de pestañas del navegador. Cada evento de autenticación, interacción de datos y flujo de trabajo colaborativo pasa por el navegador. Los atacantes se aprovechan de la confianza depositada en los sistemas de identidad en la nube, las integraciones SaaS y los flujos de autenticación, utilizando credenciales válidas, proveedores de identidad comprometidos y tokens OAuth robados. Entre los actores maliciosos vinculados a Estados, el uso indebido de cuentas válidas representó el 35 % de todos los incidentes en la nube, según el Informe Global de Amenazas 2026 de CrowdStrike.

GenAI ha abierto un nuevo canal de exfiltración

Cuando un empleado pega código fuente confidencial, datos de clientes o planes estratégicos en una herramienta de IA generativa, el navegador actúa como conducto. No hay ninguna transferencia de archivos que el sistema DLP de los terminales pueda inspeccionar, ni ningún correo electrónico saliente que la pasarela de correo pueda marcar como sospechoso. Los datos se transmiten a través de un campo de texto del navegador y, a menos que se disponga de controles de sesión, circulan sin ningún tipo de supervisión de seguridad. A medida que la IA se integra en las plataformas SaaS y en los flujos de trabajo operativos, los atacantes han comenzado a aprovechar herramientas legítimas de GenAI en docenas de organizaciones, inyectando mensajes maliciosos para robar credenciales y datos.

El acceso no gestionado y el acceso «traiga su propio dispositivo» (BYOD) se han convertido en algo permanente

La pandemia ha normalizado el uso de ordenadores portátiles de los contratistas, los dispositivos personales y los patrones de acceso mediante el navegador propio del usuario, aspectos que nunca habían sido cubiertos por los agentes de punto final. El informe DBIR 2025 de Verizon reveló que el 46 % de los dispositivos con credenciales corporativas que aparecían en los registros de los programas de robo de información no estaban gestionados, lo que supone una peligrosa brecha entre el control empresarial y el comportamiento de los usuarios. Cuando un colaborador externo abre su entorno de Salesforce en su navegador personal, su agente EDR no se está ejecutando, su sistema DLP de red no está activo y su política de categorización de URL no se aplica. La sesión del navegador es el único punto de control del que dispone, y la mayoría de las organizaciones carecen de medidas en ese ámbito.

La estrategia del adversario: cómo se materializan realmente los riesgos de los navegadores

Para comprender los riesgos de seguridad de los navegadores, es necesario relacionar las técnicas específicas de los atacantes con la sesión del navegador. Hay dos categorías principales.

Robo de credenciales y secuestro de sesión

El navegador es el mayor almacén de credenciales del mundo. Las contraseñas guardadas, las cookies de sesión, los tokens de OAuth y las aserciones de SSO se almacenan o pasan por el navegador. El malware de robo de información se centra específicamente en los almacenes de credenciales de los navegadores, recopilando contraseñas guardadas de los perfiles de Chrome, Edge y Firefox. Según el informe DBIR 2025 de Verizon, la participación de terceros en las violaciones de seguridad se duplicó hasta alcanzar el 30 % de todos los incidentes, a menudo facilitada por credenciales sustraídas de sesiones de navegador en dispositivos no gestionados. Imaginemos el caso de un colaborador externo del departamento de marketing de una empresa sanitaria que reutiliza su contraseña corporativa de SSO en una página web de compras personal. Esa página sufre una filtración, la contraseña aparece en una lista combinada y un atacante inicia sesión en el portal de SSO del colaborador desde un nodo de salida de una VPN residencial. Toda la cadena comienza y termina en el navegador.

Compromiso de seguridad «drive-by» y explotación de vulnerabilidades del navegador

La técnica T1189 de MITRE ATT&CK, denominada «Drive-by Compromise», describe cómo los atacantes pueden obtener acceso a un sistema a través de un usuario que visita un sitio web durante su navegación habitual. No se trata de una reliquia de la era de Internet Explorer: se ha observado que 41 grupos de amenazas y familias de malware conocidos utilizan esta técnica en el mundo real. Los atacantes se aprovechan de los mecanismos de notificaciones push del navegador para enviar señuelos de phishing persistentes y redireccionamientos maliciosos que sobreviven al cierre de las pestañas, ya que las notificaciones push se conceden a nivel del navegador, no a nivel de la pestaña. A diferencia de los exploits «drive-by» tradicionales, esta técnica se basa en la ingeniería social para que el usuario conceda permisos de notificación, lo que la hace eficaz incluso contra navegadores totalmente actualizados.

Los ataques modernos de tipo «watering hole» se dirigen a sitios web específicos del sector: comprometen un portal de proveedores que su equipo de compras visita a diario, inyectan código JavaScript malicioso en una página de inscripción a una conferencia o difunden publicidad maliciosa a través de redes publicitarias legítimas. Gartner señala que los parches de día cero para Chromium pueden tardar entre 24 y 72 horas en llegar a los navegadores empresariales de pila completa, un periodo de vulnerabilidad que los atacantes aprovechan activamente (Gartner, «Focus on Securing Browsers, Not Forcing a Secure Browser», octubre de 2025). La tecnología de aislamiento del navegador existe precisamente para cerrar esta brecha, ejecutando el contenido web en un entorno aislado antes de mostrárselo al usuario.

Ingeniería social a la velocidad del navegador

Las operaciones de suplantación de identidad por voz (vishing) aumentaron drásticamente en 2024 y se prolongaron hasta 2025; según Cisco Talos, el vishing representó más del 60 % de todas las intervenciones de respuesta a incidentes relacionados con el phishing en el primer trimestre de 2025, lo que lo convirtió en el vector de phishing más común con el que se topó su equipo. Muchas de estas campañas dirigen a las víctimas a páginas de captura de credenciales basadas en el navegador —réplicas exactas al píxel de las pantallas de inicio de sesión de Microsoft, Okta o Google—. Tal y como ha documentado recientemente Google Threat Intelligence (Mandiant), el atacante llama haciéndose pasar por el servicio de asistencia informática, dirige a la víctima a un portal de inicio de sesión único (SSO) de apariencia idéntica y captura tanto la contraseña como el token de autenticación multifactorial (MFA) en tiempo real, en el momento en que la víctima los introduce. Toda la cadena de ataque se desarrolla dentro del navegador y no deja ningún rastro de malware que el agente del terminal pueda detectar.

Lo que deben hacer ahora los equipos de seguridad

Para subsanar esta brecha en los navegadores no es necesario desmantelar la infraestructura de seguridad existente ni imponer un navegador propietario al que los empleados se opondrían. Lo que se requiere es ampliar los controles de seguridad de probada eficacia —DLP, CASB, SWG, RBI y ZTNA— a la sesión del navegador, que es donde realmente circulan los datos.

Aplique controles de datos en el punto de acción

Configure políticas de DLP que supervisen las operaciones del portapapeles, las subidas y descargas de archivos, así como el envío de datos en campos de formulario durante las sesiones del navegador. Cuando un empleado copie una lista de clientes de Salesforce e intente pegarla en una herramienta de IA no autorizada, la política debe detectar el patrón de datos sensibles y bloquear la operación de pegar, en lugar de registrar el evento tres días después. La plataforma SSE Skyhigh Security aplica estos controles DLP integrados en aplicaciones web, SaaS y privadas a través de un motor de políticas unificado.

Aislar la navegación de alto riesgo sin bloquearla

No es necesario bloquear todas las páginas web desconocidas. Remote browser isolation muestra el contenido web en un contenedor seguro en la nube y transmite una representación visual al navegador del usuario. Si un analista de compras necesita visitar el portal de un proveedor que no conoce, el aislamiento remoto del navegador (RBI) le permite navegar con normalidad, al tiempo que garantiza que ningún código malicioso llegue a su terminal. Esta es la respuesta práctica al MITRE ATT&CK T1189: eliminar el entorno de ejecución del exploit sin privar al usuario de su capacidad para trabajar.

Aplicar controles a nivel de sesión para los dispositivos no gestionados

Cuando los contratistas, socios o empleados accedan a aplicaciones SaaS corporativas desde dispositivos personales, aplique controles de sesión basados en proxy inverso o RBI que impidan las descargas, bloqueen el copiar y pegar de contenido sensible y añadan marcas de agua a las visualizaciones de pantalla, todo ello sin necesidad de un agente en el terminal. La norma NIST SP 800-207 define el modelo «zero trust» como una respuesta a las tendencias de las redes empresariales, entre las que se incluyen los usuarios remotos, el modelo BYOD y los activos basados en la nube, centrándose en la protección de los recursos en lugar de en los segmentos de red. Los controles de sesión del navegador constituyen el punto de aplicación que hace que este principio sea operativo para el acceso a SaaS.

Obtenga información sobre la IA «en la sombra» y el SaaS no autorizado

Utilice una combinación de CASB y SWG para detectar y clasificar todas las herramientas de IA y los servicios en la nube a los que acceden los empleados a través del navegador. Aplique políticas basadas en el riesgo: permita el uso de herramientas de IA generativa (GenAI) aprobadas con inspección DLP, oriente a los usuarios sobre los servicios de riesgo medio y bloquee los destinos de alto riesgo. Sin esta visibilidad, cada pestaña del navegador constituye un canal potencial de filtración de datos.

Urgencia y establecimiento de prioridades: por qué esto no puede esperar

Gartner prevé que, para 2028, el 25 % de las organizaciones complementarán sus herramientas actuales de acceso remoto seguro y de seguridad de los terminales mediante la implantación de al menos una tecnología de navegador empresarial seguro. En la actualidad, menos del 10 % ha adoptado navegadores empresariales seguros. Esto significa que la gran mayoría de las empresas siguen utilizando la misma arquitectura de seguridad de navegadores que tenían hace tres años, mientras que la superficie de ataque se ha ampliado de forma considerable.

Las cifras son sencillas y desfavorables. Según el Informe de Investigaciones sobre Fugas de Datos de Verizon de 2025, el uso indebido de credenciales fue el principal vector de acceso inicial para las fugas: el 22 % de todas las fugas confirmadas, con un asombroso 88 % de los ataques a aplicaciones web básicas que implicaban credenciales robadas. El navegador es donde suele iniciarse ese acceso inicial: a través de una página de phishing, un flujo de OAuth comprometido, una extensión maliciosa o un ataque de «credential stuffing» contra un inicio de sesión en una aplicación SaaS. El DBIR también documentó un aumento de los métodos para eludir la autenticación multifactorial (MFA), entre los que se incluyen la interceptación de tipo «adversario en el medio», el robo de tokens y el «bombardeo de solicitudes», lo que significa que ni siquiera las organizaciones que han implementado la MFA están a salvo. Una vez que el atacante dispone de un token de sesión válido, se encuentra dentro de sus aplicaciones SaaS con el mismo acceso que su empleado, y su agente de punto final no tiene nada que señalar.

Gartner señala que los navegadores basados en Chromium representan aproximadamente el 75 % de la cuota de mercado total de los navegadores («Focus on Securing Browsers, Not Forcing a Secure Browser», octubre de 2025), lo que convierte al navegador en una única superficie de ataque dominante compartida por casi todas las empresas. La cuestión no es si se debe invertir en seguridad de los navegadores. La cuestión es si hacerlo ahora —mientras aún dispone de tiempo para implementar controles— o después de que una brecha de seguridad mediada por un navegador le obligue a actuar.

El Modelo de Madurez de «Zero Trust» v2.0 de la CISA ofrece un enfoque para llevar a cabo esfuerzos continuos de modernización relacionados con el modelo «Zero Trust», estructurados en torno a cinco pilares: identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos. El navegador se sitúa en la intersección de los cinco. Es el dispositivo a través del cual se verifica la identidad, la aplicación mediante la cual se accede a los datos y la vía de red por la que fluye toda transacción SaaS. Proteger la sesión del navegador no es un proyecto minoritario, sino un requisito fundamental para la madurez del modelo «Zero Trust».

Cómo elaborar una estrategia de seguridad para el navegador: por dónde empezar

Los equipos de seguridad no tienen por qué intentar abarcarlo todo. Establezca prioridades en función de la exposición al riesgo y la viabilidad operativa.

Fase 1 — Visibilidad (semanas 1 a 4). Active la función de detección del CASB y el registro del SWG para identificar todas las aplicaciones SaaS, herramientas de IA y servicios en la nube a los que se accede a través de los navegadores de los empleados. Cuantifique el uso de la «TI en la sombra» y de la «IA en la sombra ». Identifique qué tipos de datos sensibles circulan a través de las sesiones del navegador.

Fase 2 — Controles en línea (meses 2-3). Implemente políticas de DLP en la secure web gateway para inspeccionar las cargas, descargas, operaciones de copiar/pegar y el envío de formularios. Comience por los tipos de datos de mayor riesgo: información de identificación personal (PII), registros financieros, código fuente y datos sanitarios regulados.

Fase 3 — Aislamiento y acceso no gestionado (meses 3 a 6). Active remote browser isolation categorías web de alto riesgo, dominios sin clasificar y sesiones SaaS en dispositivos no gestionados. Implemente controles CASB de proxy inverso para el acceso de contratistas y de dispositivos personales (BYOD) a aplicaciones SaaS críticas.

Fase 4 — Aplicación continua (en curso). Integre la telemetría de las sesiones del navegador con sus plataformas SIEM y XDR. Correlacione los eventos relacionados con el navegador —ubicaciones sospechosas de inicio de sesión, patrones inusuales de acceso a datos SaaS, uso anómalo de herramientas de IA— con las señales de los terminales y de identidad para la detección de amenazas entre dominios.

Este enfoque por fases se ajusta a lo que recomiendan la norma NIST SP 800-207 y el Modelo de Madurez de «Zero Trust» de la CISA, que abogan por una progresión gradual desde la madurez tradicional hasta la óptima. Cada fase reduce una superficie de riesgo concreta, al tiempo que contribuye a alcanzar una postura de seguridad integral en el navegador.