En abril de 2024, bastó un solo comentario malicioso bajo el directo de una celebridad para secuestrar 90.000 sesiones de espectadores. El atacante inyectó un script corto que robaba cookies de YouTube, redirigía a los fans a una estafa cripto y desataba una oleada de compras no autorizadas. El exploit no era un zero-day, sino un fallo clásico de cross-site scripting, la misma familia de bugs que persigue a la web desde los años 90.
El XSS casi nunca llega a los titulares porque no deja malware en disco. Corre en silencio dentro del navegador, roba datos, reescribe contenido y se aprovecha de la confianza. Entender cómo funciona, y cómo bloquearlo o contenerlo, sigue siendo clave tanto para quien programa como para cualquier usuario de a pie.
XSS en cristiano
El cross-site scripting ocurre cuando un atacante consigue que un sitio incruste un script malicioso en una página que otros usuarios van a ver. El navegador se fía del script porque procede de un dominio legítimo. A partir de ahí, el script corre con los permisos de la víctima y accede a cookies, tokens de sesión, contenido de la página o elementos del DOM.
La analogía para quien no escribe código a diario. Imagina un post-it pegado en el tablón de anuncios de una empresa. Si nadie modera el tablón, cualquiera puede colgar instrucciones falsas que los compañeros acabarán siguiendo. El XSS es la versión digital: contenido en el que no se debería confiar, colado en un contexto que sí parece de confianza.
Tres tipos principales (más un par de casos límite)
Conocer las variantes del XSS te ayuda a diagnosticar vulnerabilidades rápido. Hay tres principales y un puñado de casos límite que siguen asomando en campañas reales.
Stored XSS. El script malicioso se guarda en el servidor (en una base de datos, un CMS o similar) y se sirve a cada visitante. Las secciones de comentarios y los sistemas de tickets de soporte son el escenario clásico. El impacto suele ser amplio, porque cada lector dispara la payload.
Reflected XSS. El script malicioso llega de vuelta directamente en la respuesta del servidor, normalmente a través de parámetros de URL. La víctima pincha en un enlace preparado, el servidor devuelve esa entrada dentro de la página y la payload se ejecuta.
DOM-based XSS. La payload nunca llega al servidor. Se ejecuta entera en el navegador, manipulando el DOM. El servidor puede no enterarse de nada, lo que dificulta la detección y explica por qué este tipo reaparece una y otra vez en los informes de incidente.
El self-XSS (engañar al usuario para que pegue scripts en la consola) y el XS-Search (abusar de los formularios de búsqueda para inferir estados) siguen apareciendo en ataques actuales. Los patrones de defensa se solapan con los arreglos clásicos del XSS.
Cómo funciona un ataque XSS, paso a paso
Reconstruir una cadena de explotación típica deja claro dónde puedes meter controles para cortarla.
- 1
Encontrar un punto de entrada
El atacante localiza un formulario, un parámetro de URL o un campo almacenado que devuelve contenido sin una limpieza decente. - 2
Preparar la payload
Escribe JavaScript que robe cookies, altere elementos del DOM, cargue malware o redirija tráfico. - 3
Hacer llegar la payload
Vía un enlace preparado, una cuenta comprometida o contenido ya almacenado. - 4
Ejecutarla en el navegador de la víctima
El navegador se fía de la payload porque llega desde el dominio legítimo. - 5
Exfiltrar datos o pivotar
Los scripts envían lo robado a endpoints del atacante o inyectan más malware.
Qué consiguen los atacantes
El XSS ya no se queda en un simple defacement. Las campañas actuales lo usan para ataques de alto impacto, y hay cuatro resultados que se repiten una y otra vez.
Secuestro de sesión. Roban tokens de autenticación para suplantar a usuarios en portales bancarios, paneles de administración y plataformas SaaS. La víctima nunca llega a ver el robo.
Robo de credenciales. Inyectan formularios de login falsos o retocan los existentes para pescar usuario y contraseña dentro del navegador, antes incluso de que el formulario real llegue a enviarse.
Distribución de malware. Cargan scripts remotos que sueltan ransomware o mineros de cripto. Resulta especialmente eficaz en ataques de supply chain, cuando un script de terceros considerado fiable acaba comprometido.
Manipulación social. Reescriben contenido o cuelan mensajes en el chat para empujar al usuario hacia acciones peligrosas o transferencias de dinero. Cuando el sitio en el que confía le dice que transfiera, transfiere.
Cinco casos reales en distintos sectores
Estos incidentes (recogidos de divulgaciones públicas y reportes del sector) dan una idea del rango de impacto que puede tener un XSS.
Plataforma de medios (2024). Un XSS en la moderación de comentarios dejó que los atacantes dieran likes automáticos a canales de estafa. El golpe reputacional fue real: una caída del 7 % en las métricas de confianza de los suscriptores y una semana de limpieza.
Marketplace de ecommerce (2023). Un reflected XSS en los códigos de descuento desviaba a los compradores hacia páginas de checkout de phishing. Impacto: 4,1 millones de dólares en cargos fraudulentos antes de que el equipo se diera cuenta del patrón.
Portal sanitario (2022). Un stored XSS en la mensajería con pacientes robaba cookies de sesión y dejaba al aire resultados de laboratorio. La cosa terminó con una notificación HIPAA y un acuerdo de 1,2 millones de dólares.
App bancaria (2021). Un DOM-based XSS vía widgets colaba solicitudes de transferencia no autorizadas. La reacción rápida del SOC evitó las pérdidas, pero el incidente arrastró una auditoría regulatoria de varios meses.
CMS gubernamental (2020). Un XSS viejo en un CMS legacy permitió el defacement de avisos municipales sobre COVID-19. El daño se midió en confianza pública en plena crisis, no en dólares.
Por qué el XSS sigue dando guerra en 2025
Pese a los frameworks modernos, el XSS aparece año tras año en el OWASP Top 10. Las razones son estructurales, no técnicas.
Bases de código enormes siguen tirando de concatenación de cadenas y de plantillas anticuadas. Los widgets de terceros (píxeles de marketing, chatbots, analítica) añaden una superficie de ataque que el equipo de seguridad no controla. Los equipos de ingeniería nuevos heredan patrones inseguros sin conocer los incidentes pasados que dieron forma al código. Los escáneres automatizados se dejan fuera las payloads DOM-based, porque analizan la salida renderizada en el servidor y no el DOM en vivo, y los pentests manuales suelen mirar hacia otra parte.
Protección para el día a día
No puedes parchear internet, pero sí puedes limitar el alcance del daño. Cuatro hábitos cubren la mayor parte del riesgo real.
Abre los enlaces dudosos dentro de Browser.lol, así ningún script se ejecuta en tu máquina. Desactiva las extensiones de navegador que no uses, porque muchas amplían la superficie de ataque XSS. Mantén el navegador al día: una CSP (Content Security Policy) moderna bloquea scripts inline y buena parte de las técnicas XSS de siempre. Cierra sesión en los sitios sensibles cuando no los estés usando: las cookies robadas pierden valor enseguida si las sesiones caducan pronto.
Checklist para devs y equipos de seguridad
Si construyes o mantienes apps web, hay cinco controles que son los que más rentabilidad dan.
Escapar la salida según el contexto. HTML, JavaScript, URL y CSS piden reglas de escaping distintas. Una función "sanitize" genérica casi siempre deja fuera alguna categoría.
Apostar por frameworks con saneamiento integrado. React, Vue y Angular reducen la manipulación directa del DOM y hacen que el camino seguro sea el camino por defecto.
Desplegar una Content Security Policy. Restringe las fuentes de scripts y prohíbe los scripts inline siempre que puedas. La CSP es una de las defensas con mejor relación coste-impacto que han entrado nunca en un navegador.
Usar linters y SAST orientados a la seguridad. Los plugins de seguridad de ESLint, Semgrep y SonarQube cazan patrones comunes pronto, cuando arreglarlos sale barato.
Programar revisiones de seguridad periódicas. Incluye laboratorios de payloads XSS en QA y en el alcance del bug bounty. Meter Browser.lol en QA te permite ejecutar payloads de prueba de concepto poco fiables sin poner en riesgo las máquinas de los devs.
Contener el script, controlar el riesgo
El XSS no va a desaparecer. La superficie de ataque crece con cada widget, cada píxel de marketing y cada integración de terceros. Pero no estás indefenso. Un código disciplinado evita vulnerabilidades, una buena higiene del usuario limita la exposición y los navegadores virtuales hacen que un script malicioso, aunque se ejecute, no llegue a tocar tu hardware.
Trata cada sitio desconocido como un posible vector XSS. Navega desde un entorno aislado, mantén las credenciales y las cookies compartimentadas y empuja a los equipos a ir a la raíz del problema. Así es como se evita que un script invisible acabe convirtiéndose en un incidente de varios millones.
Llévate un escritorio entero a cualquier dispositivo
Prueba Browser.lol gratis y trabaja como en un PC desde el móvil.
Abrir mi navegador en la nubeSin descargas • Funciona en cualquier dispositivo
