Svelte 4.0.0 marks a significant update to the Svelte framework, introducing changes that impact both developers and the overall performance of web applications. Compared to the previous stable version, 3.59.2, Svelte 4 boasts a refined dependency structure. While both versions maintain core dependencies like acorn, code-red, and css-tree, Svelte 4 updates and refines the versions of many of these dependencies, and introduces new ones such as @jridgewell/trace-mapping. This contributes to enhanced stability and potentially improved performance.
Developers will notice differences primarily in the development dependencies. Svelte 4 utilizes more modern tools like vitest, esbuild, and dts-buddy for testing, bundling, and type checking respectively, hinting at a shift towards a more streamlined and efficient development workflow. The update of @sveltejs/eslint-config suggests potential changes in linting rules and best practices, encouraging developers to adhere to the latest Svelte coding standards.
Notably, the older version 3.59.2 relies on now outdated versions of tools such as rollup, and typescript that have been updated in Svelte 4. Furthermore, some packages have been totally removed such as rollup plugins @rollup/plugin-replace, @rollup/plugin-sucrase and @rollup/plugin-virtual suggesting significant changes in the bundling and transpilation process. This newer stack promises improved build times and a more modern development experience. These changes collectively aim to improve developer experience, making Svelte 4 especially appealing for developers looking to leverage the most up-to-date tooling and coding conventions for building reactive web applications.
All the vulnerabilities related to the version 4.0.0 of the package
Svelte has a potential mXSS vulnerability due to improper HTML escaping
A potential XSS vulnerability exists in Svelte for versions prior to 4.2.19.
Svelte improperly escapes HTML on server-side rendering. It converts strings according to the following rules:
" -> "& -> &< -> <& -> &The assumption is that attributes will always stay as such, but in some situation the final DOM tree rendered on browsers is different from what Svelte expects on server-side rendering. This may be leveraged to perform XSS attacks. More specifically, this can occur when injecting malicious content into an attribute within a <noscript> tag.
A vulnerable page (+page.svelte):
<script>
import { page } from "$app/stores"
// user input
let href = $page.url.searchParams.get("href") ?? "https://example.com";
</script>
<noscript>
<a href={href}>test</a>
</noscript>
If a user accesses the following URL,
http://localhost:4173/?href=</noscript><script>alert(123)</script>
then, alert(123) will be executed.
XSS, when using an attribute within a noscript tag