¿Qué es el cross-site scripting (XSS)?
El cross-site scripting, o XSS, es un ataque web en el que el criminal inyecta un script malicioso dentro de un sitio legítimo y confiable, para que se ejecute en el navegador de quien visite la página. Como el código viene de un sitio en el que la víctima confía, el navegador lo ejecuta sin sospechar, y así el atacante roba sesiones, contraseñas y datos de los propios usuarios del sitio. En resumen: el sitio de la empresa se vuelve el arma usada contra sus clientes.
Cómo funciona el cross-site scripting
Un sitio muestra, de vuelta en la pantalla, mucho de lo que los usuarios escriben: un comentario, un nombre de perfil, el término de una búsqueda. El XSS ocurre cuando ese texto se repite sin tratamiento e incluye un script. El navegador del próximo visitante recibe el código como si fuera parte legítima de la página, y lo ejecuta.
Encontrar el punto de eco
El atacante busca un campo cuyo contenido el sitio muestra a otros usuarios sin limpiar: una caja de comentarios, un campo de perfil, un resultado de búsqueda que repite lo que se escribió.
Inyectar el script
En lugar de un texto común, inserta un fragmento de código de navegador (un script). Si el sitio guarda o repite ese contenido sin tratarlo, el código queda plantado.
La víctima carga la página
Cuando otra persona abre la página, el sitio entrega el script junto con el contenido legítimo. Para el navegador de la víctima, el código vino de una fuente confiable, así que se ejecuta sin barrera.
El script actúa
Ya ejecutándose en el navegador de la víctima, el código roba las cookies de sesión (para hacerse pasar por ella), captura lo que escribe, redirige a una página falsa o realiza acciones en su lugar.
Fuente: OWASP (el XSS forma parte de la categoría A03:2021, Inyección).
Los tres tipos de XSS
- XSS reflejado El script viaja en un enlace malicioso. La víctima hace clic, el sitio devuelve el código en la respuesta y se ejecuta en su navegador. Alcanza un objetivo por vez y no queda guardado; suele llegar por correo o mensaje.
- XSS almacenado El script queda guardado en el servidor del sitio (en un comentario, un perfil, un campo de registro) y se sirve a todos los que abran esa página. Es el más dañino, porque alcanza a muchos visitantes sin exigir un nuevo clic.
- XSS basado en DOM El ataque ocurre por completo en el navegador de la víctima: un código del propio sitio procesa la entrada de forma insegura y dispara el script sin que llegue a pasar por el servidor. Es más difícil de percibir desde afuera.
Lo que está en juego para el negocio
El XSS importa porque invierte la relación de confianza: es el propio sitio de la empresa, aquel en el que el cliente confía, el que entrega el golpe. Un script bien colocado secuestra la sesión del usuario conectado (apoderándose de su cuenta), roba datos de formulario o redirige a una página falsa, todo bajo el nombre y la apariencia de la marca. El perjuicio no es solo técnico: es la confianza del cliente y la reputación que sostienen el negocio, sin contar la exposición de datos personales y el costo promedio de US$ 4,44 millones por brecha en el mundo (IBM, 2025). Por eso el XSS integra la Inyección, la 3ª mayor categoría de riesgo del OWASP Top 10, y se trata con el mismo rigor que una falla que abre la puerta del cliente.
Cómo protegerse del cross-site scripting
La defensa contra el XSS parte de una regla simple: el sitio nunca puede repetir, como si fuera código, un texto que vino de afuera. Eso se garantiza con capas de disciplina en el desarrollo:
- Codifique la salida (output encoding)Es la corrección central. Antes de mostrar cualquier contenido del usuario, el sitio lo convierte a texto puro, de modo que un script aparezca como letras en la pantalla y no se ejecute. Trata el dato como dato, nunca como comando.
- Valide y trate la entradaVerifique y limpie lo que los usuarios envían, rechazando contenido con marcas y comandos donde solo se espera texto. Es la capa complementaria a la codificación de salida.
- Adopte una Política de Seguridad de Contenido (CSP)La CSP le dice al navegador qué scripts tienen permiso para ejecutarse en ese sitio. Aun si un XSS pasa, reduce lo que el script puede hacer, funcionando como una traba adicional.
- Agregue un firewall de aplicación web (WAF)El WAF filtra el tráfico de la aplicación y bloquea patrones conocidos de XSS antes de que lleguen al usuario. Es una capa extra, no un sustituto de la corrección en el código.
- Pruebe de forma continuaEl escaneo automatizado y la prueba de penetración encuentran los puntos de eco vulnerables antes que el atacante. El XSS desaparece del sitio cuando se busca a propósito, campo por campo.
En la práctica
En el XSS, quien ataca a su cliente es su propio sitio. Por eso la defensa no es desconfiar del visitante, sino nunca dejar que el sitio repita, como si fuera de él, un texto que vino de afuera. El campo de comentario más inocente, mostrado sin tratamiento, es suficiente para transformar la confianza en la marca en un vector de ataque.
Cómo Zamak protege contra el XSS
Zamak Technologies protege la relación de confianza que el XSS explota, actuando junto a su equipo de desarrollo, no en su lugar: prueba las aplicaciones en busca de los puntos de eco vulnerables, señala la corrección en el origen (codificación de salida, validación de entrada, Política de Seguridad de Contenido) y refuerza el entorno con una capa de firewall de aplicación web. En lugar de descubrir la falla cuando un cliente sea alcanzado, su empresa la encuentra y la cierra antes. Es parte de la Ciberseguridad gestionada del Método Zamak, y un buen punto de partida es el diagnóstico de ciberseguridad.