Skip to content

Depurar DOM XSS siguiendo el flujo real de datos

DOM XSS se entiende mejor siguiendo fuentes, transformaciones y sinks en lugar de probar payloads al azar.

Publicado el 1 min de lectura

DOM XSS rara vez se encuentra en una sola línea obvia. La fuente puede estar en la URL, un mensaje, local storage o una respuesta JSON. El sink puede aparecer mucho después, en otro componente.

Por eso el flujo de datos importa más que el payload inicial.

Empieza por la fuente

Identifica de dónde sale el valor controlado: location.search, location.hash, postMessage, document.referrer o estado persistido. Luego observa si la aplicación lo decodifica, lo concatena o lo transforma antes de renderizarlo.

Termina en el sink

Busca escrituras en innerHTML, outerHTML, insertAdjacentHTML, document.write o APIs de framework que desactiven escaping. El hallazgo necesita unir fuente y sink con una ruta reproducible.

Reporta la ruta

Un buen reporte no dice solo “payload ejecuta alert”. Explica: la query q se lee, se pasa al componente de preview, se concatena en HTML y termina en innerHTML. Eso es corregible.

Artículos relacionados

Las pruebas XSS responsables dependen del alcance, la evidencia, la minimización de datos y saber cuándo una prueba de concepto ya es suficiente.
Una mirada práctica a por qué las herramientas XSS no deberían procesar en servidor URLs internas, fragmentos privados o notas sensibles de pruebas.
La elección del payload importa menos que el contexto de inyección: HTML, atributos, URLs, scripts y sinks DOM fallan de formas distintas.