En resumen
Qué se mide
tres señales de riesgo, no una vulnerabilidad confirmada.
Cuáles
si la política de seguridad de contenido protege frente a scripts, si hay parámetros de la URL reflejados en el HTML y si se usan funciones peligrosas del navegador.
Por qué importa
el XSS es la CWE-79, dentro de la categoría de inyección que OWASP sitúa en el tercer puesto de su Top 10 de 2021.
Severidad en Wakaris
Importante. Salta en el 1,5 % de las páginas analizadas, según el propio catálogo de Wakaris.
Qué es y qué mide este hallazgo
La documentación de MDN define el XSS —cross-site scripting— como un ataque en el que un atacante logra que el sitio objetivo ejecute código malicioso como si formara parte del propio sitio. Hay tres variantes: la reflejada, donde el dato llega en la URL y la página lo devuelve dentro de su HTML; la almacenada, donde el dato queda guardado —un comentario, por ejemplo— y se sirve a todo el que entre; y la basada en el DOM, propia de páginas que montan su contenido en el navegador.
Conviene ser exacto con lo que este hallazgo dice y lo que no. No es un ataque de prueba ni una confirmación: es un recuento de tres condiciones que hacen el ataque más fácil. Puedes tener las tres y no ser vulnerable, si el código escapa correctamente todo lo que recibe; y puedes no tener ninguna y serlo por una vía que no se ve desde el HTML servido. Es una medida de exposición, y así hay que leerla.
Cómo se mide
Wakaris analiza la URL que le indiques y devuelve las tres señales por separado, con el recuento de cada una: cuántos parámetros de la dirección aparecen reflejados en el HTML, cuántos usos de funciones peligrosas del navegador encuentra y si la política de seguridad de contenido protege frente a la ejecución de scripts. Verlas separadas es lo que permite decidir por dónde empezar.
Hay dos límites que este artículo declara en lugar de esconder. El primero es de método: el hallazgo se obtiene leyendo la página, no atacándola, así que mide indicios y no explotabilidad. El segundo es de documentación: el catálogo de Wakaris no dice qué funciones concretas cuenta como peligrosas ni con qué criterio considera que una política protege, y usa un único corte —más de cero— para las tres señales, sin tramos. Un parámetro reflejado y veinte producen el mismo hallazgo con la misma severidad.
Por qué importa
La consecuencia es que el código de otro se ejecuta con los permisos de tu página: puede leer lo que la persona escribe, actuar en su nombre dentro de su sesión o cambiar lo que ve. Y la variante almacenada es la peor, porque MDN señala que es especialmente grave, ya que el contenido infectado se sirve a todos los usuarios que acceden a la página, cada vez que acceden.
Sobre la frecuencia hay un dato de fuente, aunque conviene leerlo con cuidado: OWASP clasifica el XSS como CWE-79 dentro de la categoría de inyección, que en su Top 10 de 2021 ocupa el tercer puesto, con 33 CWEs agrupadas, 274.228 ocurrencias registradas y una tasa de incidencia media del 3,37 % frente a una máxima del 19,09 %. Esas cifras son de la categoría entera, no de este hallazgo, así que no se pueden presentar como la tasa del XSS. Lo que sí dicen es que el 94 % de las aplicaciones del estudio se probaron contra alguna forma de inyección: es un problema que se busca en todas partes.
Causas comunes
La primera y más frecuente es devolver en el HTML un dato que ha llegado de fuera sin transformarlo. El ejemplo que usa MDN es una página que espera el nombre del usuario en un parámetro de la URL, lo extrae y lo usa para construir un saludo personalizado: si nadie escapa ese valor, ahí entra código.
La segunda son las funciones del navegador que interpretan lo que reciben. MDN las agrupa en dos familias: las que tratan su argumento como HTML —innerHTML, outerHTML, insertAdjacentHTML() y document.write()— y las que lo ejecutan como JavaScript, entre ellas eval(), setTimeout() y setInterval(). Pasarles algo que no controlas del todo es el camino corto al problema.
La tercera es una política de seguridad de contenido que no protege. MDN avisa de que los desarrolladores deberían evitar 'unsafe-inline', porque destruye buena parte del propósito de tener una política; los orígenes con comodín tienen el mismo efecto por otra vía. Y la cuarta, más silenciosa: usar un sistema de plantillas que escapa automáticamente y saltárselo justo en el sitio donde entra el dato de fuera.
Cómo solucionarlo
Wakaris te dice cuál de las tres señales aparece, y de eso depende el orden. MDN plantea dos defensas y no son alternativas: una evita que el dato se vuelva ejecutable y la otra impide que se ejecute si la primera falla.
La primera es escapar y sanear la entrada. Escapar convierte en texto inofensivo los caracteres peligrosos: < pasa a su entidad, y lo mismo las comillas. Los sistemas de plantillas modernos ya lo hacen solos, así que el trabajo real suele ser localizar dónde se ha desactivado. Sanear es quitar del HTML lo que no debe estar: etiquetas de script o manejadores de eventos en línea.
La segunda es la política de seguridad de contenido, que MDN describe como defensa de respaldo. El enfoque recomendado es una política estricta, con un valor de un solo uso o una huella que le indique al navegador qué scripts espera encontrar; si lleva uno de los dos, el navegador ignora 'unsafe-inline'. Y si tu web monta contenido en el navegador, la API de tipos de confianza garantiza que nada llegue a esas funciones sin pasar antes por el saneado.
Tabla con las tres señales del hallazgo y la defensa que corresponde a cada una
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla con las tres señales del hallazgo y la defensa que corresponde a cada una. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: riesgo, xss, tabla, señales, hallazgo, defensa, corresponde
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Riesgo de XSS. Cuenta tres señales que hacen más probable que alguien consiga que mi web ejecute código ajeno: parámetros de la dirección reflejados en el HTML, uso de funciones del navegador que interpretan lo que reciben, y una política de seguridad de contenido que no protege frente a scripts. Referencia: es un recuento de indicios, no una vulnerabilidad confirmada; el corte es más de cero en cualquiera de las tres. Pega aquí el resultado de Wakaris: cuál de las tres señales te ha salido, con qué recuento y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿La página analizada recibe datos de quien la visita: un buscador interno, un formulario, filtros, o parámetros en la dirección? c) ¿Hay contenido que escriben terceros y se muestra a todo el mundo, como comentarios, reseñas o perfiles? d) ¿La página monta su contenido en el navegador con JavaScript, o llega ya hecha desde el servidor? e) ¿Sabes si usáis un sistema de plantillas, y si alguien ha desactivado el escapado automático en algún punto? f) ¿Tienes puesta una política de seguridad de contenido? ¿La configuró alguien o viene del hosting? g) Si hay que tocar código o cabeceras, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. En particular, no me digas que soy vulnerable: este hallazgo mide indicios, no explotabilidad. 5. No me propongas cambios técnicos irreversibles o de riesgo (cabeceras del servidor, tocar el escapado de las plantillas, cambios directos en producción) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Si necesitas un dato que solo se obtiene analizando la web (confirmar el recuento, qué parámetro se refleja, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/riesgo-de-xss Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Riesgo de XSS. Consiste en que mi página presente señales que faciliten que alguien consiga ejecutar código ajeno en ella. Referencia: se cuentan tres señales —parámetros de la dirección reflejados en el HTML, funciones del navegador que interpretan lo que reciben, y una política de seguridad de contenido que no protege— y el corte es más de cero en cualquiera de ellas. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba analizando el código de mi página, y tú no puedes analizar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. Y aclárame también que este hallazgo mide indicios de riesgo, no una vulnerabilidad confirmada. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Tu web tiene buscador interno, filtros o formularios cuyos valores acaban en la dirección de la página? b) ¿Se muestra en tu web contenido que escriben otras personas (comentarios, reseñas, mensajes, perfiles)? c) ¿La web monta su contenido en el navegador, tipo aplicación de una sola página, o llega ya hecha desde el servidor? d) ¿En qué plataforma está? (WordPress, Shopify, web a medida, otra; o no lo sé) e) ¿Sabes si tiene puesta una política de seguridad de contenido, o si alguien ha revisado la seguridad de la web alguna vez? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que aparezcan esas señales, y de cuál de las tres sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá qué señales aparecen, con qué recuento y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. No me propongas probar ataques contra mi propia web. 6. Si al comprobarlo resulta que aparecen señales, dime que el siguiente paso es entender cómo me afectan y cómo reducirlas en mi caso concreto. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/riesgo-de-xss Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Este hallazgo significa que mi web es vulnerable? +
No. Cuenta señales que hacen el ataque más probable, no un ataque conseguido. Se obtiene leyendo la página, no atacándola, así que mide exposición y no explotabilidad. Puedes tener señales y estar protegido, y puedes no tenerlas y ser vulnerable por otra vía.
¿No basta con poner una política de seguridad de contenido? +
No, y MDN lo dice expresamente: la política es una defensa de respaldo, para cuando la primera falla. Además, una política con 'unsafe-inline' destruye buena parte de su propio propósito. Lo primero sigue siendo escapar y sanear todo lo que entra.
¿Qué es una función peligrosa del navegador? +
Una que interpreta lo que le pasas en vez de tratarlo como texto. MDN señala dos familias: las que lo leen como HTML, como innerHTML o document.write(), y las que lo ejecutan como JavaScript, como eval(), setTimeout() y setInterval().
¿Por qué la política de seguridad aparece también en otro hallazgo? +
Porque se lee dos veces con criterios distintos: en las cabeceras de seguridad se comprueba que exista y esté bien formada, y aquí solo si protege frente a la ejecución de scripts. Wakaris los presenta separados; si te salen los dos, el arreglo suele ser el mismo.
Fuentes citadas
- developer.mozilla.orgCross-site scripting (XSS), MDN: definición del ataque, las tres variantes, la gravedad de la variante almacenada, la lista de funciones que interpretan HTML o ejecutan JavaScript, el escapado y saneado, la política como defensa de respaldo y la API de tipos de confianza.
- developer.mozilla.orgContent-Security-Policy, MDN: el aviso de evitar
'unsafe-inline', el bloqueo del JavaScript en línea por defecto, y el funcionamiento de los valores de un solo uso y de las huellas. - owasp.orgA03:2021 – Injection, OWASP: el XSS como CWE-79 dentro de la categoría de inyección, sus 33 CWEs, las 274.228 ocurrencias, las tasas de incidencia media y máxima y el 94 % de aplicaciones probadas.
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.