Definición de seguridad del lado del cliente
En el contexto de la seguridad web, la «seguridad del lado del cliente» protege a sus usuarios de que se les sirva código malicioso en el navegador desde su sitio web. Las inyecciones de código malicioso incluyen skimmers de tarjetas de crédito, superposiciones visuales que redirigen a los usuarios a páginas de phishing o esquemas de fraude sofisticados como el fraude de enlaces de afiliados.
Los sitios web no sirven código malicioso a sus usuarios de forma intencionada. Sin embargo, los «ataques del lado del cliente» inyectan código a través de puntos de entrada ocultos: scripts de terceros procedentes de herramientas que integra en su sitio web (etiquetas de analítica, bibliotecas de fuentes, herramientas de código abierto, plugins) y scripts propios en los que los atacantes colocan código ofuscado que su equipo de seguridad no detecta.
«Seguridad del lado del cliente» en diferentes contextos
| Vector de seguridad del lado del cliente | Propósito | Protege contra | Utilizado por |
|---|---|---|---|
| 1. Instalar un fragmento de código en su propio sitio web | Proteger a los usuarios de ataques como el web skimming. Cumplir con marcos normativos como PCI DSS o GDPR. | Inyecciones de código que se sirven a los navegadores de los usuarios desde su sitio web. | Sitios de comercio electrónico, plataformas SaaS y cualquier empresa que procese pagos o recopile datos personales en la web. |
| 2. Instalar software en el navegador del usuario final (extensión de navegador) | Orientado al cliente: Advierte a los consumidores sobre sitios de phishing o descargas inseguras. Orientado al empleado: Aplica políticas de prevención de pérdida de datos y controla lo que los empleados pueden compartir a través del navegador. | Amenazas que el usuario encuentra mientras navega. Filtración no autorizada de datos desde el navegador. | Los proveedores de seguridad para consumidores ofrecen extensiones de navegación segura. Las empresas las despliegan para controlar la actividad del navegador de los empleados y prevenir la fuga de datos. |
| 3. Instalar software en el dispositivo del usuario final | Orientado al cliente: Protege las sesiones detectando malware presente en el dispositivo del cliente. Orientado al empleado: Monitoriza los dispositivos gestionados por la empresa en busca de malware. | Keyloggers, troyanos y otro malware que se ejecuta localmente en el dispositivo del usuario. | Los bancos ofrecen a sus clientes protección de endpoints gratuita para proteger las sesiones de banca online del malware local. Los empleadores despliegan agentes EDR en los dispositivos de la empresa para detectar amenazas. |
Cuando asistimos a conferencias de ciberseguridad, mencionar la «seguridad del lado del cliente» evoca percepciones distintas según el área de seguridad en la que trabaje cada persona. El denominador común es que la «seguridad del lado del cliente» se centra en monitorizar un entorno que se ejecuta en el dispositivo del usuario final, no en sus propios servidores, APIs o tráfico de red.
cside opera dentro del primer vector de seguridad del lado del cliente de la tabla anterior. Los comercios y las plataformas de software implementan un fragmento de código en su sitio web que nos permite monitorizar el tiempo de ejecución del navegador durante las sesiones de los visitantes. Como ejemplo simplificado, funciona de manera similar a las herramientas de analítica que instala en su sitio. Pero nosotros monitorizamos señales de brechas de seguridad y fraude, no con fines de marketing.
¿Por qué proteger el lado del cliente?
En cside, nuestro equipo tiene un compromiso profundo con la seguridad del lado del cliente (el nombre de la empresa deriva de client-side). La empresa nació porque observamos que las herramientas tradicionales de seguridad web tenían una visibilidad limitada sobre el tiempo de ejecución del navegador de los usuarios, dejando un enorme punto ciego. Como co-presidentes de la comunidad W3C Anti-Fraud Browser Security, nuestra misión es proteger a consumidores y comercios del fraude en sitios web.
Se presta mucha atención a proteger la cadena de suministro. Los desarrolladores analizan los paquetes NPM. La infraestructura está blindada. Los firewalls y los WAFs se consideran una línea base. Y la seguridad en la nube se ha convertido en toda una categoría. Pero una de las superficies de ataque más grandes y de más rápido crecimiento sigue ignorándose: el lado del cliente. Mastercard señaló que casi tres cuartas partes de las brechas divulgadas públicamente involucran skimming digital.
La seguridad del lado del cliente abarca todo lo que se ejecuta dentro del navegador del usuario: JavaScript de terceros, píxeles, iFrames, formularios, SDKs y cualquier código que se descarga y ejecuta después de que la página carga. Esta parte del stack casi siempre se ignora durante las auditorías, y sin embargo es responsable de algunos de los ataques más dañinos.
Los scripts de terceros se cargan directamente en el navegador y se ejecutan con acceso completo al DOM. Estos scripts pueden escanear formularios, registrar el comportamiento del usuario, modificar el contenido de la página y exfiltrar datos sin llegar a tocar su servidor. Aquí es donde más importa la protección del lado del cliente: no solo monitorizar de dónde vienen los scripts, sino qué hacen realmente.
Y las cosas salen mal. Con frecuencia. El ataque a la cadena de suministro de Polyfill afectó a más de 490.000 sitios web inyectando código malicioso en una biblioteca de código abierto previamente de confianza. Antes de eso, Kaiser Permanente filtró los datos de 13,4 millones de pacientes debido a scripts del lado del cliente integrados que enviaban datos a destinos no autorizados.
Si no realiza un análisis activo del lado del cliente, no está protegiendo a sus usuarios. Porque cuando algo sale mal, la responsabilidad recae sobre usted, no necesariamente sobre el proveedor que sirvió el script.
La seguridad del lado del cliente ya no es opcional. Si su sitio procesa pagos, recopila información personal o requiere que los usuarios inicien sesión, es un objetivo. Y el navegador es donde ocurren esos ataques.
Amenazas y tipos de ataque del lado del cliente
1. Control de acceso del lado del cliente deficiente
El control de acceso se suele considerar una preocupación del lado del servidor. Pero los fallos en el control de acceso del lado del cliente son reales y a menudo se pasan por alto. El JavaScript en el navegador puede utilizarse para manipular el DOM y acceder a datos o funciones que nunca debieron estar expuestos. Si un script no está correctamente aislado (o si los tokens se dejan en memoria, por ejemplo), resulta sencillo para los atacantes obtener acceso sin activar las comprobaciones del backend.
Este es uno de los tipos de vulnerabilidades del lado del cliente más silenciosos. Y como ocurre en el navegador, los registros tradicionales no lo detectan.
2. Cross-Site Scripting (XSS) basado en el DOM
El XSS basado en el DOM es un ataque común y persistente. Ocurre cuando JavaScript lee una entrada no confiable (como parámetros de URL, por ejemplo) y la escribe de vuelta en la página sin sanitización. Esta forma de inyección no depende de las respuestas del servidor, lo que dificulta su detección con los firewalls de aplicaciones web tradicionales.
Las herramientas de análisis del lado del cliente son a menudo la única forma de detectarlo en tiempo real. Sin ellas, los atacantes pueden inyectar scripts arbitrarios y comprometer completamente la sesión del navegador del usuario.
3. Dominios expirados
Cuando un dominio referenciado en su código expira, cualquiera puede comprarlo. Si su JavaScript sigue apuntando a ese dominio para un script, una hoja de estilos o incluso un enlace codificado, el nuevo propietario controla lo que se sirve. Los atacantes buscan activamente estas oportunidades porque el dominio ya tiene una relación de confianza con su sitio y sus usuarios.
Nuestro equipo de investigación de seguridad encontró una vulnerabilidad de dominio expirado en el sitio web de Oracle, donde un archivo JavaScript referenciaba un dominio que había caducado y estaba disponible para su compra.
4. Filtración de datos sensibles
La filtración de datos del lado del cliente es uno de los riesgos más costosos en la seguridad de JavaScript. Ocurre cuando los scripts recopilan información sensible (como nombres, correos electrónicos o datos de tarjetas de crédito, por ejemplo) y la transmiten a dominios externos. A veces es intencionado. Con frecuencia no lo es.
Cuando Kaiser Permanente filtró más de 13,4 millones de registros, fue porque el código del lado del cliente integrado enviaba datos a terceros sin el consentimiento del usuario. La monitorización del lado del cliente habría detectado los intentos de exfiltración antes de que los datos abandonaran la página.
5. Componentes vulnerables y desactualizados
Las bibliotecas JavaScript desactualizadas son uno de los puntos de entrada más explotados en los ataques del lado del cliente. A menudo se obtienen de CDNs o proveedores de terceros y nunca se vuelven a revisar. Si esa biblioteca tiene un CVE conocido y su sitio la carga, está expuesto.
Esto es exactamente lo que hizo tan efectivo el ataque de Polyfill. Un script ampliamente utilizado fue comprometido en el origen, y la mayoría de las empresas ni siquiera sabían que lo estaban cargando. La protección del lado del cliente debe incluir el seguimiento de versiones de bibliotecas para anticiparse a este tipo de riesgos.
6. Falta de control sobre el origen de terceros
La mayoría de los ataques del lado del cliente no parten de su código. Provienen de un origen de terceros en el que ha confiado sin verificación. Estos scripts se cargan con permisos completos dentro de su entorno de navegador, dándoles acceso a todo lo que el usuario ve y hace.
Cuando se permite que el JavaScript de terceros se ejecute libremente, usted pierde el control. A menos que utilice una Content Security Policy (CSP) sólida y un análisis del lado del cliente en tiempo real, no tiene forma de saber qué está haciendo ese script. Sin el análisis en tiempo real del lado del cliente, una CSP resulta con frecuencia insuficiente para detenerlo.
El compromiso de la cadena de suministro del Web SDK de AppsFlyer es un ejemplo reciente. Los atacantes secuestraron el DNS de un SDK de marketing de confianza y sirvieron un payload que robaba criptomonedas a miles de sitios que no tenían idea de que sus scripts habían cambiado.
7. JavaScript drift
El JavaScript drift ocurre cuando el contenido de un script cambia con el tiempo sin que nadie lo note. Un script que era seguro la semana pasada puede comportarse de forma completamente diferente ahora, especialmente si se sirve desde una fuente remota. Algunos atacantes explotan esto introduciendo comportamiento malicioso de forma gradual para evitar la detección.
En cside, no nos limitamos a rastrear la URL. Registramos y analizamos el payload completo de cada script, cada vez. Así es como detectamos nuevas vulnerabilidades del lado del cliente antes de que se conviertan en brechas.
8. Datos sensibles almacenados en el lado del cliente
Cuando JavaScript almacena datos en localStorage, sessionStorage o cookies, cualquier script de la página puede acceder a ellos, incluidos los de terceros. Esto crea una enorme superficie de ataque para el secuestro de sesiones, el robo de tokens y la filtración entre sitios.
Si almacena cualquier dato sensible en el cliente (véanse los ejemplos anteriores), necesita un alcance estricto, lógica de expiración y monitorización en tiempo real para detectar abusos. La mayoría de los sitios web omiten esto por completo.
9. Fallos en el registro y la monitorización del lado del cliente
No se puede proteger lo que no se observa. La mayoría de las organizaciones siguen tratando el registro como una responsabilidad del lado del servidor. Pero cuando los scripts se ejecutan en el navegador y los ataques ocurren en tiempo real, también se necesita monitorización del lado del cliente.
Esto incluye visibilidad sobre las interacciones con formularios, el comportamiento de los scripts, las solicitudes salientes inesperadas y los errores de JavaScript. Sin ella, está volando a ciegas.
10. No utilizar los controles de seguridad estándar del navegador
Existen defensas nativas del navegador. Pero muchos sitios las ignoran. La Content Security Policy (CSP), la Subresource Integrity (SRI), el sandboxing de iframes... todos son mecanismos para reducir el riesgo de scripts maliciosos y contenido inyectado. Sin embargo, la mayoría de los equipos los configuran mal o los desactivan por completo para evitar que las cosas se rompan.
Si quiere una seguridad real del lado del cliente, empiece por aplicar los controles que el navegador ya soporta.
11. Incluir lógica propietaria en el cliente
Su frontend es visible para cualquiera. Eso incluye la lógica de negocio, los algoritmos de precios, las reglas de enrutamiento internas y cualquier otra cosa que envíe para que se cargue en el navegador. Es habitual encontrar procesos sensibles codificados directamente en JavaScript, donde pueden ser sometidos a ingeniería inversa o abusados.
Esto no es solo un riesgo para la privacidad, también lo es para la propiedad intelectual. Si se ejecuta en el lado del cliente, está expuesto. Y si está expuesto, debe ser monitorizado.
«Los desarrolladores suelen decir "nunca confíes en el lado del cliente", y sin embargo, de forma rutinaria inyectamos decenas de peticiones del lado del cliente de terceros. La realidad es que el lado del cliente se ha convertido en la principal superficie para los ataques silenciosos. Es donde prosperan las vulnerabilidades, precisamente porque es muy fácil evadir la detección.»
— Simon Wijckmans, CEO de Cside
Por qué la detección del lado del cliente no puede depender únicamente de los feeds de amenazas
La mayoría de las herramientas que afirman ofrecer protección del lado del cliente se basan en dos cosas:
- Listas de permitidos
- Feeds de inteligencia de amenazas precompilados.
Los atacantes ahora diseñan payloads del lado del cliente para evadir estos métodos de detección. Cambian el contenido del script de forma dinámica. Apuntan solo a sitios web específicos. Sirven código malicioso una única vez.
Si su método de detección solo vigila dominios conocidos o firmas de ataques pasados, no verá lo que se avecina. El script puede estar ya comprometido, pero su herramienta no lo sabe porque nadie lo ha reportado todavía.
Por eso la inspección de payloads JavaScript en tiempo real es el único enfoque fiable para el análisis del lado del cliente.
Marcos normativos que exigen controles de seguridad del lado del cliente
PCI DSS 4.0.1
PCI DSS 4.0.1 exige a las empresas monitorizar y autorizar todos los scripts del lado del cliente. Los requisitos 6.4.3 y 11.6.1 se volvieron obligatorios en marzo de 2025 y ahora se aplican activamente. Si su sitio procesa pagos, eso significa visibilidad en tiempo real sobre lo que se ejecuta en el navegador, no solo una lista estática de dominios aprobados.
Disponemos de una guía sobre los mecanismos exactos del lado del cliente que satisfacen este mandato.
GDPR, CCPA y otros marcos relacionados con la privacidad
Si se recopilan o transmiten datos personales a través de scripts de terceros sin consentimiento ni supervisión, está expuesto. No importa si el script provino de un proveedor de confianza. Usted sigue siendo responsable.
Los artículos 25, 28, 30 y 32 del GDPR, entre otros, establecen la necesidad de controles del lado del cliente, como la visibilidad sobre la actividad de recopilación de terceros y las salvaguardas contra fugas de datos.
HIPAA, SOC 2 y DORA avanzan en la misma dirección. La protección real del lado del cliente ya no es solo una cuestión de seguridad. Es una cuestión de cumplimiento normativo. Y la aplicación se está intensificando.
Diferentes enfoques para la seguridad del lado del cliente
1. Content Security Policies (CSPs)
Las CSPs son controles a nivel de navegador que restringen qué dominios pueden servir scripts en sus páginas. Son un buen punto de partida, pero tienen limitaciones reales:
- Solo validan de dónde proviene un script, no qué hace una vez que se ejecuta.
- No pueden detectar scripts que cambian su comportamiento en función del usuario, la sesión o la geografía.
- Las violaciones de CSP generan errores en la consola que llevan a los desarrolladores a relajar las políticas o desactivarlas por completo.
El ataque a la cadena de suministro de Polyfill mostró exactamente qué ocurre cuando se confía en una URL de origen que acaba siendo comprometida. El dominio estaba permitido por la CSP, y el código malicioso se ejecutó libremente.
2. Enfoques basados en crawlers o «escáneres»
Las herramientas de crawler visitan su sitio de forma programada y comprueban si hay scripts maliciosos. El problema es que la detección se retrasa y es fácil de evadir:
- Los atacantes pueden identificar los crawlers y servirles código limpio mientras entregan payloads maliciosos a los usuarios reales.
- La mayoría de los crawlers muestrean una fracción del tráfico, por lo que los ataques dirigidos a usuarios o regiones específicas pasan desapercibidos.
- Nunca ven el script real que recibe el navegador de un usuario real durante una sesión en vivo.
3. Detección del lado del cliente basada en JS
Las herramientas basadas en JavaScript se ejecutan dentro del navegador para observar la actividad de los scripts en tiempo real. Pero tienen debilidades significativas:
- Actúan como trampas, pero como viven en el mismo entorno que los scripts que monitorizan, los atacantes pueden detectarlas y evitarlas.
- No tienen contexto histórico, por lo que no pueden rastrear cómo ha cambiado un script a lo largo del tiempo ni apoyar una investigación forense tras un incidente.
Con regulaciones como PCI DSS que ahora exigen controles de scripts del lado del cliente, estos enfoques se utilizan a menudo para marcar la casilla de cumplimiento rápidamente. Pero no ofrecen protección real. Dejan a las empresas expuestas a ataques que se adaptan más rápido de lo que estas herramientas pueden seguir.
Lea aquí una comparativa en profundidad y una guía de selección.
Cómo cside protege el lado del cliente
Construimos cside para ofrecer monitorización del lado del cliente en tiempo real y protección frente a amenazas JavaScript sin ralentizar su sitio.
- Inspección de payloads: Capturamos y comparamos los payloads completos de los scripts en cada solicitud de fetch y carga, no solo el dominio o el hash.
- Gestión de scripts de terceros: Monitorice, versione y bloquee los scripts de terceros para que no cambien silenciosamente en producción.
- Detección de exposición de datos: Detectamos datos que se filtran hacia endpoints inesperados antes de que se conviertan en un problema de cumplimiento.
- Preparación para el cumplimiento normativo: Tanto si se está preparando para PCI DSS 4.0 como si gestiona el riesgo bajo GDPR, le ayudamos a mantenerse listo para las auditorías.
