¿Qué es XSS y cómo impedir que se ejecute código en tu página web?
Publicado el 2026-10-20 por frfrand
Cross-Site Scripting explicado: diferencias entre texto y código, casos en comentarios y formularios, escape por contexto y sanitización segura.
XSS significa Cross-Site Scripting y describe una familia de vulnerabilidades en las que contenido no confiable termina interpretándose como código activo dentro de una página web. En muchos casos el origen es un dato que introdujo una persona: un comentario, una biografía, un nombre de producto o un parámetro de la URL.
El problema no es permitir que alguien escriba texto. El problema aparece cuando la aplicación trata ese texto como si fuera parte de las instrucciones que debe ejecutar el navegador.
El ejemplo de una sección de comentarios
Imaginá una web donde los usuarios pueden publicar reseñas. Cada reseña debería mostrarse como texto, aunque contenga signos extraños, comillas o fragmentos de código.
Si el sistema introduce ese contenido en el HTML sin el tratamiento adecuado, el navegador puede interpretarlo como marcado o ejecutar instrucciones que no pertenecen al sitio.
Esto puede permitir acciones no deseadas en el contexto de la página, acceso a ciertos datos disponibles para los scripts o manipulación del contenido que ve el visitante. El impacto depende de los permisos, la arquitectura y las protecciones existentes.
¿Por qué no alcanza con bloquear la palabra «script»?
Porque los navegadores interpretan HTML, atributos, JavaScript, URLs y CSS de maneras diferentes. Una lista improvisada de palabras prohibidas no contempla todos los contextos.
La defensa correcta depende de dónde se está colocando el dato. Mostrar texto entre etiquetas HTML no requiere exactamente el mismo tratamiento que utilizar un valor dentro de una URL o un atributo.
Por eso OWASP recomienda codificación de salida adaptada al contexto y, cuando realmente se necesita aceptar HTML, sanitización mediante herramientas apropiadas.
¿Qué es escapar contenido?
Escapar significa representar ciertos caracteres como datos para que no se interpreten como sintaxis activa en ese contexto.
Un ejemplo fácil: si querés mostrar literalmente <b>Hola</b> como texto, no debería transformarse en una etiqueta HTML activa. Un framework puede convertirlo en texto visible o utilizar entidades apropiadas.
Muchas bibliotecas modernas de interfaz aplican protecciones de forma predeterminada cuando insertan valores como texto. Pero hay funciones especiales para insertar HTML sin ese tratamiento; utilizarlas con contenido no confiable aumenta el riesgo.
¿React y otros frameworks evitan XSS automáticamente?
Ayudan muchísimo cuando utilizás las funciones seguras, pero no eliminan cualquier posibilidad.
Por ejemplo, React suele escapar texto interpolado de manera normal. Sin embargo, existen mecanismos para insertar HTML de forma deliberada. Si alimentás esos mecanismos con contenido no confiable sin sanitizar, podés reintroducir el problema.
También importan las URL, las bibliotecas externas, las versiones y los componentes que convierten datos en código de maneras especiales.
¿Qué pasa si necesito permitir texto enriquecido?
En un blog o editor puede ser razonable permitir títulos, enlaces y negritas. En ese caso no podés mostrar absolutamente todo como texto plano, pero tampoco conviene aceptar HTML arbitrario.
La alternativa suele ser utilizar un formato limitado y una biblioteca de saneamiento mantenida, con una lista controlada de elementos y atributos permitidos. Además, es importante no modificar después el HTML saneado de una forma que vuelva a hacerlo inseguro.
¿Una política CSP lo resuelve?
Content Security Policy puede reducir determinados riesgos al limitar de dónde se cargan scripts y qué puede ejecutarse. Pero no debe ser la única defensa.
Un WAF tampoco reemplaza una implementación segura. Algunos ataques XSS se producen completamente dentro de la lógica del navegador y no necesariamente pasan por un filtro de peticiones del servidor.
Tres errores comunes
Confiar en lo que viene de la base de datos. Que un dato esté almacenado no significa que sea seguro: quizá lo introdujo otro usuario hace un mes.
Escapar en el lugar equivocado. Un método adecuado para texto HTML puede no ser suficiente para una URL o un contexto JavaScript.
Permitir HTML por comodidad. Si solo necesitás texto, mostralo como texto. Reducir funciones peligrosas facilita mucho la seguridad.
¿Cómo se relaciona con ArduMaker?
Una aplicación desplegada en un VPS de ArduMaker puede estar perfectamente configurada en cuanto a puertos y HTTPS y, aun así, presentar XSS si su frontend interpreta mal contenido externo. La prevención se trabaja principalmente en el código y en la forma de representar datos.
En resumen: XSS aparece cuando contenido no confiable deja de ser tratado como dato y se convierte en código activo. Las defensas centrales son salida segura, codificación contextual y sanitización cuando sea necesaria.
Fuente: Guía de prevención XSS de OWASP · Seguridad de contenidos en MDN.