Un ticket de soporte, un resultado de búsqueda o un comentario pueden parecer contenido normal hasta que una aplicación web los trata como código. El cross-site scripting (XSS) aprovecha ese fallo: contenido controlado por un atacante se ejecuta dentro de una página en la que otra persona confía. Las consecuencias dependen del sitio vulnerable, los permisos de esa persona y las defensas que existan.
Un XSS puede tener consecuencias sin instalar un archivo. El código inyectado podría leer datos visibles en la página, cambiar lo que muestra o enviar solicitudes en su nombre. Quien desarrolla debe impedir que datos no fiables se conviertan en contenido ejecutable; quien navega debe conocer tanto las ventajas como los límites del aislamiento. La guía de MDN sobre XSS explica cómo lo procesa el navegador.
Qué es el XSS
El XSS ocurre cuando una página interpreta datos no fiables como contenido ejecutable. El script se ejecuta en el origen de esa página, puede interactuar con su DOM y, a menudo, enviar solicitudes al sitio como el usuario que ha iniciado sesión. La política del mismo origen sigue limitando el acceso a otros orígenes. Si una cookie lleva el atributo HttpOnly, el script no puede leerla mediante document.cookie, aunque podría actuar dentro de la página autenticada.
El ajuste SameSite determina principalmente cuándo envía el navegador una cookie en solicitudes entre sitios distintos. Puede ayudar a evitar algunas falsificaciones de solicitudes, pero no elimina un script que ya se ejecuta en la página del propio sitio. La referencia de MDN sobre Set-Cookie explica las funciones distintas de SameSite y HttpOnly.
Piensa en un tablón de anuncios: una persona puede colgar una nota, pero no cambiar las instrucciones ni los controles del tablón. El XSS equivale a tratar esa nota como si formara parte del propio tablón. La barrera falla cuando los datos se insertan en un contexto donde pueden ejecutarse.
Tres tipos principales (más un par de casos límite)
Los tres nombres indican dónde entran los datos no fiables y cuándo se vuelven ejecutables. Pueden solaparse: el servidor podría entregar datos que después el código del navegador inserta de forma insegura en el DOM.
XSS almacenado. Una aplicación guarda contenido controlado por un atacante, quizá en un comentario, un perfil o un ticket de soporte, y lo muestra a otras personas. La exposición depende de quién pueda verlo y de cómo lo represente la aplicación.
XSS reflejado. El servidor incluye en su respuesta un dato de la solicitud, a menudo un parámetro de la URL, sin codificarlo de forma segura para el lugar donde va a mostrarse. Un enlace preparado puede llevar a alguien hasta esa respuesta.
XSS basado en el DOM. El código del navegador lee datos no fiables y los pasa a una operación peligrosa como innerHTML. Los datos pueden venir de una URL, una respuesta del servidor u otra fuente; lo que define este caso es la transformación insegura en el navegador. Consulta la guía de OWASP sobre XSS basado en el DOM.
El self-XSS es distinto: un atacante convence a alguien para que ejecute código por su cuenta, por ejemplo, pegándolo en las herramientas de desarrollo. Las XS-Leaks permiten deducir información de otros orígenes a partir de efectos observables y son otra clase de problema. El núcleo del XSS sigue siendo que datos ajenos se convierten en contenido activo en una página de confianza.
Cómo funciona un ataque XSS, paso a paso
Un recorrido habitual muestra dónde pueden interrumpir el ataque los controles de la aplicación.
- 1
Encontrar un punto de entrada
El atacante encuentra un comentario, un parámetro de URL, un mensaje u otro dato que acabará apareciendo en una página. - 2
Llegar a una salida insegura
La aplicación inserta ese dato en un lugar donde el navegador podría interpretarlo como HTML o código en vez de texto. - 3
Llevar el contenido a la víctima
El atacante consigue que alguien abra la página afectada, por ejemplo, mediante un enlace preparado o contenido compartido. - 4
Ejecutarse en la página afectada
Si el navegador lo ejecuta, el código comparte el origen de la página y puede interactuar con contenido y funciones disponibles allí, sujeto a las restricciones del navegador y del sitio. - 5
Aprovechar el acceso disponible
Según la aplicación, el código puede cambiar la página, leer datos accesibles o enviar solicitudes con la sesión actual. Lo que consiga depende de las defensas del sitio.
Qué puede hacer el código inyectado
El XSS puede tener más efectos que cambiar el aspecto de una página. Su impacto depende de los datos y las acciones disponibles allí. Estos cuatro resultados muestran posibilidades, no una clasificación de frecuencia.
Acciones en la cuenta. El código inyectado puede enviar solicitudes desde una página autenticada y quizá leer tokens que la aplicación exponga a JavaScript. HttpOnly impide leer directamente esas cookies, pero no bloquea por sí solo las acciones en el mismo origen. Consulta la guía de MDN sobre cookies.
Captura de credenciales. Un formulario alterado podría recoger una contraseña u otros datos mientras la persona los escribe. Esto requiere que los introduzca en esa página: el XSS no revela automáticamente una contraseña guardada en otro lugar.
Manipulación de la página. El código puede cambiar enlaces, instrucciones o datos de una transacción que ve el usuario. También podría cargar otros recursos web dentro de los límites de la política del sitio. Para ejecutar malware en el dispositivo haría falta además explotar el navegador o conseguir que alguien abra una descarga.
Exposición de datos. Un script podría leer información que ya aparece en la página y enviarla fuera si lo permiten los controles de red. La política del mismo origen aún restringe la lectura de otras webs. El riesgo afecta a los datos sensibles y permisos de la página comprometida.
Cinco ejemplos hipotéticos
Estos ejemplos son hipotéticos, no informes de incidentes reales. Cada uno muestra dónde conviene revisar la barrera entre datos y código.
Sitio comunitario. La vista previa de comentarios representa el HTML enviado como contenido activo. Si un moderador la abre mientras tiene la sesión iniciada, el código inyectado podría actuar en la interfaz de moderación. Hay que representar el contenido de forma segura y revisar este procedimiento con permisos elevados.
Tienda en línea. Un término de búsqueda vuelve en una respuesta HTML sin la codificación adecuada al contexto. Quien siga una URL preparada podría ver un enlace de pago cambiado. Que la página tenga el dominio legítimo no demuestra que ese enlace sea seguro.
Portal de pacientes. Un mensaje guardado aparece en el navegador de un profesional sanitario. Aunque las cookies sean HttpOnly, el código inyectado podría leer datos presentes en la página o enviar solicitudes que el profesional tiene permiso para realizar. Importan tanto el control de acceso como la representación segura.
Panel financiero. El código del navegador lee un fragmento de URL y lo inserta con innerHTML. Un enlace malicioso podría cambiar lo que ve un cliente. Las comprobaciones y confirmaciones del servidor aún podrían impedir una transferencia no autorizada, pero habría que corregir el fallo del DOM igualmente.
Sitio de información pública. Una plantilla antigua de un gestor de contenidos trata el campo del título como HTML fiable. Un editor malicioso o una cuenta comprometida podría alterar avisos públicos. Revisa las plantillas antiguas y los permisos de quienes las alimentan, además de los componentes nuevos.
Por qué sigue habiendo XSS
Los frameworks actuales codifican muchos valores de forma segura por defecto, pero es posible saltarse esas protecciones al insertar HTML sin procesar, usar funciones inseguras del DOM, tomar atajos en plantillas o añadir código de terceros. OWASP incluye la inyección, también el XSS, entre los riesgos de las aplicaciones web. Su guía de prevención del XSS explica por qué ninguna medida cubre todos los contextos.
Las aplicaciones grandes mezclan plantillas antiguas, componentes nuevos, texto enriquecido aportado por usuarios y scripts de otros proveedores. La solución depende de dónde entran los datos y dónde terminan: texto HTML, atributos, URL, bloques de script y funciones del DOM tienen reglas distintas. Las herramientas automáticas ayudan, pero probar solo respuestas del servidor puede dejar fuera las transformaciones del navegador. Añade pruebas en navegador y revisión del código que maneja datos no fiables.
Cómo reducir el riesgo al navegar
No puedes arreglar una web vulnerable que visitas, pero sí limitar lo que expones en ella. Estos pasos reducen algunos riesgos sin garantizar protección frente al XSS.
Comprueba la dirección antes de introducir credenciales o confirmar acciones importantes. Mantén el navegador actualizado y elimina las extensiones innecesarias. Separa cuentas o perfiles cuando tus actividades requieran distintos niveles de confianza. Si crees que una web está comprometida, cierra sesión y revisa tu cuenta desde un dispositivo fiable; que el cierre invalide otras sesiones depende del servicio. Browser.lol puede ejecutar el código de la web en un navegador remoto, pero un XSS aún puede afectar a tu sesión de cuenta y a lo que escribas o apruebes allí. El visor, el portapapeles y las descargas también conectan la sesión con tu dispositivo.
Medidas para equipos de desarrollo y seguridad
La prevención empieza en la aplicación. Prueba estas cinco medidas en los contextos que utiliza realmente.
Codifica la salida según su contexto. El texto HTML, los atributos, las URL, JavaScript y CSS requieren tratamientos distintos. Si solo necesitas texto, usa funciones que inserten texto. Para HTML enriquecido, utiliza una herramienta de saneamiento mantenida.
Usa conscientemente las protecciones del framework. React, Vue y Angular pueden codificar los valores mostrados. Las funciones de HTML sin procesar y las modificaciones directas del DOM se saltan parte de esa protección. Revísalas con atención.
Establece una CSP restrictiva. Una Content Security Policy bien diseñada, basada en valores nonce o huellas, puede limitar la ejecución de scripts tras una inyección. Es una defensa adicional, no sustituye la codificación ni el saneamiento. Consulta la guía de OWASP sobre CSP.
Revisa los datos y las operaciones peligrosas. El análisis estático puede señalar patrones de riesgo, como asignaciones a innerHTML sin comprobar. Acompáñalo de pruebas de páginas representadas y de los caminos que siguen los datos en el navegador.
Examina los procesos con permisos elevados. Prueba dónde ve el personal contenido de usuarios, dónde se admite texto enriquecido y qué páginas pueden iniciar acciones delicadas. Hacer pruebas en un navegador remoto puede reducir la exposición local al código, pero no convierte una demostración de ataque en inofensiva. Usa cuentas de prueba y evita secretos reales.
Evita que los datos se conviertan en código
El XSS surge cuando falla la barrera entre datos y código en una aplicación. Codificar según el contexto, usar funciones seguras del DOM, tratar con cuidado el HTML enriquecido y aplicar una CSP restrictiva reduce el riesgo de que los datos no fiables se ejecuten. Los atributos de las cookies y las comprobaciones del servidor pueden limitar algunas consecuencias, pero ninguno cura todos los fallos de XSS.
Un navegador remoto cambia dónde se ejecuta el código de la web. No arregla el sitio vulnerable ni protege una cuenta de las acciones realizadas en la sesión remota. Separa las cuentas sensibles, verifica las acciones importantes y corrige en origen el punto donde los datos se convierten en código. Estas medidas se complementan porque afrontan distintas partes del riesgo.
¿Necesitas una sesión aislada para tu próxima tarea?
Abre un navegador aislado desde el que ya usas y ponte manos a la obra.
Iniciar una sesiónSin instalar otro navegador • Las funciones dependen del plan
