Por qué un generador de payloads XSS debe quedarse del lado del cliente
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.
Un generador XSS que envía cada entrada a un backend pide el tipo equivocado de confianza.
Durante una evaluación, el texto pegado rara vez es un ejemplo limpio. Puede contener hostnames internos, rutas de staging, IDs de tenant, fragmentos HTML de un panel privado, cabeceras CSP o notas de un reporte todavía no público. Enviar ese material a un servidor solo para ensamblar un payload es innecesario.
El navegador puede hacer el trabajo.
Los logs son el fallo aburrido
La mayoría de filtraciones no son cinematográficas. Un proxy puede registrar cuerpos de petición durante una ventana de debug. Una plataforma de observabilidad puede capturar una excepción. Un CDN puede guardar metadatos suficientes para reconstruir lo ocurrido.
Para una herramienta XSS, la ejecución local elimina toda una clase de exposición. IndexedDB, exportaciones y plantillas personalizadas siguen necesitando controles, pero la herramienta no se convierte automáticamente en un recolector remoto de datos de auditoría.
La normalización del servidor engaña
Los backends suelen mutar la entrada: decodifican una vez, normalizan rutas, rechazan caracteres, convierten Unicode inválido o truncan logs. Acabas depurando la herramienta en vez del objetivo.
submitted: %253Cimg%2520src=x%2520onerror=alert(1)%253E
api saw: %3Cimg%20src=x%20onerror=alert(1)%3E
target: <img src=x onerror=alert(1)>
Una herramienta local debe mostrar cada transformación con claridad: payload bruto, mutación, URL encoding, entidades HTML, Base64 y salida final.