Cross-site scripting

Un nombre debe mostrarse como un nombre. El problema empieza cuando la aplicación permite que ese valor se convierta en instrucciones para el navegador. Cross-site scripting, o XSS, implica ejecutar script en el contexto web de la aplicación. Mostrar marcado inesperado no basta para demostrar ejecución.

Parte del uso previsto

Para texto sencillo, utiliza una API de texto como textContent o la presentación normal del framework. Si se permite HTML enriquecido, hace falta un saneador mantenido y una política explícita. Codificar todo el marcado conservaría el texto, pero eliminaría el formato solicitado.

Un valor puede atravesar varios intérpretes. El control debe corresponder al destino final, no solo al lugar donde se introdujo.

EXPLORA EL CONCEPTO

Elige la política de presentación

El mismo perfil incluye tres tipos de contenido. Compara el control que necesita cada uno.

Nombre visible

Trátalo como texto mediante una API de texto o la presentación normal del framework. Un nombre no necesita interpretarse como HTML.

Enlace personal

Analiza la URL, impón esquemas y destinos permitidos y trata correctamente componentes y contexto de atributo HTML. Codificar la URL no decide por sí solo qué se permite.

Biografía con formato

Si se necesita HTML enriquecido, usa un saneador mantenido con una política definida. Evita transformaciones posteriores que vuelvan a introducir marcado inseguro; los campos de texto simple no requieren ese análisis.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Compara los tres campos del perfil. El uso previsto determina la política de presentación; los intérpretes anidados pueden requerir más de un tratamiento.

Cuatro destinos, distintas decisiones

Codificar una URL para transportarla no impide que exprese un esquema o destino prohibido. La codificación no sustituye esa política. Si la URL termina en un atributo HTML, también necesita tratamiento adecuado para ese atributo.

Escapar una cadena JavaScript no basta cuando se inserta dentro de un elemento script de HTML: el intérprete HTML también procesa ese elemento. Es preferible entregar los datos por separado o usar serialización del framework que contemple el contexto exterior. No coloques valores no confiables en manejadores de eventos ni posiciones ejecutables. La guía de OWASP explica estas distinciones.

Entrega y ejecución son dimensiones distintas

Un valor reflejado llega con una solicitud; uno almacenado persiste y aparece después. XSS basado en DOM describe un flujo del cliente hacia un destino inseguro. Las categorías pueden superponerse: un valor almacenado puede acabar en un destino DOM. Un problema reflejado no exige siempre pulsar un enlace.

Escenario: el perfil del club

El club presenta el nombre como texto, valida el enlace según esquemas permitidos y sanea la biografía con formato. Son tres decisiones de presentación, no una función universal.

Si queda una ruta insegura, el impacto depende del origen afectado, los datos accesibles, permisos, controles del navegador e interacción necesaria. HttpOnly impide leer esa cookie mediante API de script; no bloquea toda acción autenticada. CSP añade protección, pero no sustituye la presentación correcta. XSS almacenado no es automáticamente más grave que reflejado.

Un hallazgo útil identifica origen del dato, contexto final, público afectado, control ausente e impacto sustentado, sin recopilar sesiones ajenas.

Revisa el consumidor final, no solo el primer filtro

El club ficticio aporta tres registros de diseño. P1 muestra el nombre mediante una API de texto. P2 acepta una biografía con una política limitada de texto enriquecido, la sanea y después la envía a un complemento de formato sin revisar. P3 crea un enlace web tras comprobar un esquema permitido y tratar el contexto del atributo.

P1 corresponde al propósito de texto plano. P3 tiene una política de destino y tratamiento de renderizado; ninguno sustituye al otro. P2 sigue incompleto: el complemento puede cambiar el marcado o su interpretación. El registro dice que no se ha revisado su comportamiento, no que esté confirmada la ejecución de scripts.

PrediceLas pruebas del saneador son satisfactorias. ¿Qué evidencia sigue haciendo falta para P2?

Revisa la ruta completa a través del complemento hasta el uso final del navegador. Establece que el formato permitido sigue permitido y que las transformaciones posteriores no convierten contenido excluido en activo. Probar solo el saneador no cubre un consumidor sin examinar.

Elige el contrato de contenido más pequeño que sirva a la función. Si la biografía solo necesita énfasis y listas, define esas funciones admitidas y usa herramientas mantenidas para aplicar la política. No consideres confiable contenido enriquecido solo porque pasó por almacenamiento o por una respuesta API firmada.

La verificación necesita expectativas positivas y negativas. Un nombre debe conservar puntuación legítima como texto visible. El formato permitido de la biografía debe funcionar; el no admitido debe eliminarse o rechazarse según el contrato documentado. La validación de enlaces debe aplicar la política de destino y conservar el renderizado correcto.

Registra versiones de componentes y uso final en el resultado. Así podrá revisarse la decisión cuando cambie un complemento. Las cookies y CSP pueden reducir algunas consecuencias, pero no aportan la evidencia pendiente sobre la ruta completa de renderizado de P2.