FlawOpen

flawopen.com/XSS en JavaScript/Svelte

¿Svelte protege contra XSS por defecto?

Página de referencia
En palabras sencillas

Piensa en `{comment}` como imprimir una nota: los signos angulares siguen siendo texto visible. `{@html comment}` es como pedir al tipógrafo que interprete las marcas de la página como instrucciones de diseño. Si proceden de una fuente no confiable, el navegador puede interpretarlas como HTML y provocar XSS.

ARRIESGADO
<p>{@html comment}</p>
// el valor se interpreta como marcado HTML
SEGURO
<p>{comment}</p>
// se escapa automáticamente

La regla

Svelte compila la salida habitual de {expression} como texto escapado, por lo que el valor no se interpreta como marcado HTML. En cambio, {@html} representa intencionadamente una cadena HTML. La documentación de Svelte advierte que, para evitar XSS, el valor debe escaparse o estar controlado. Trátalo como un punto de inserción HTML sensible y usa un sanitizador mantenido cuando necesites texto enriquecido escrito por usuarios.

Cómo revisar tu código

Busca `{@html}` en los archivos `.svelte`. Para cada coincidencia, rastrea el origen del valor y todas sus transformaciones. Considera no confiables la entrada del usuario, los datos externos y el contenido de usuario almacenado. Si debe mostrarse texto, usa `{expression}`. Si necesitas HTML enriquecido, pásalo por un sanitizador HTML mantenido y prueba que elimine el marcado no permitido.

grep -rn "{@html" --include="*.svelte" .

HTML enriquecido: mantenga el límite de sanitización

Use `{expression}` cuando el contenido deba mostrarse como texto. Si los usuarios necesitan crear HTML, sanitice el contenido final con un sanitizador HTML mantenido, como DOMPurify, antes de pasarlo a `{@html}`. No concatene ni modifique el resultado sanitizado después, pues podría anular la protección. Mantenga el sanitizador actualizado y permita solo los elementos y atributos de marcado que necesite el producto. La sanitización HTML no hace que el mismo valor sea seguro en contextos JavaScript, CSS o URL.

Referencias

Véase también Cross-Site Scripting (XSS, CWE-79): cómo funciona y cómo evitarlo en cada lenguaje — flawopen.com ¿La carga de SVG implica riesgo de XSS? Riesgo de XSS con Vue v-html WKWebView: ¿HTML no confiable seguro? XSS reflejado, almacenado y basado en DOM: ¿en qué se diferencian? Riesgos de seguridad de addJavascriptInterface en Android Protección XSS de Angular: valores seguros y APIs de omisión