Should Svelte/SvelteKit expose which versions are running?

[Rich-Harris]

Context

Tools like Wappalyzer use heuristics to determine which technologies are used on a given page. Some of them can be a bit brittle. For example Svelte is detected via the svelte- CSS scoping classname prefix...

"dom": "[class*='svelte-']"

...which only works for apps that use Svelte's built-in CSS scoping (rather than, say, Tailwind). This mechanism is also subject to change in future, at which point the heuristic will fail.

There's also no way to know which version of Svelte (or SvelteKit) is running. This information is potentially useful (hypothetical use cases: devtools, tracking the speed of adoption of new versions, reaching out to sites that are running a version with a known vulnerability) and, in fact, the CWV tech report plans to add version information to the report in future. Currently, Svelte is systematically underrepresented in reports of technology usage, and will be excluded altogether from these more granular reports.

The question under discussion here is whether Svelte and SvelteKit should expose information about whether they're being used on a given page, and if so, whether they should expose which versions are in use.

Security and privacy

Of course, exposing version information provides potential attackers with information about which sites to target, if a version with a known vulnerability exists. Having said that, both client-side libraries and servers have been exposing version information for many years (see e.g. a default Apache 404 page, or log _.VERSION on any site running Underscore), and to my knowledge this isn't a practice that's frowned upon.

If we do deem granular version information to be too sensitive, then there are alternatives (which might differ between Svelte and SvelteKit — for example we could provide major/minor/patch for Svelte but only major for SvelteKit):

• expose nothing
• expose a boolean ('this site is running some version of Svelte/SvelteKit')
• expose a major version ('this site is running Svelte 4 and SvelteKit 2')
• expose major/minor
• expose major/minor/patch

Crucially, an explicit mechanism (as opposed to a heuristic based on implementation details) can have an opt-out mechanism, so exposing the boolean is arguably more privacy/security conscious than the status quo (and certainly not less).

For this to be at all useful, it would have to be opt-out rather than opt-in.

Implementation

For Svelte, we could add something like this to an internal module...

// svelte/internal/tracking.js
(window.__svelte_versions ??= []).push(VERSION);

...and then import that module in every compiled component (unless the compiler were configured to opt out):

import 'svelte/internal/tracking';

For SvelteKit, it would be natural to use the <meta name="generator"> tag, which is used by things like Wordpress:

<meta name="generator" content="SvelteKit 1.20.0">

Should we do this?

The consensus among maintainers was that exposing a boolean (with an opt-out) for both Svelte and SvelteKit would make sense, since it would simply be a more reliable and privacy-forward version of existing detection mechanisms. We're undecided about whether or not we should expose version information, however.

It's important to us that decisions like these happen with the community's consent and consultation, so we'd very much welcome your thoughts on this question.

This post has been edited, so the first couple of replies might not make much sense

[Conduitry]

I'm not jazzed about this. Where would this go? As one-time top-level code in svelte/internal? Would there be any way to opt out of it?

[Rich-Harris]

As one-time top-level code in svelte/internal? Would there be any way to opt out of it?

If it was a compiler option like track: false then we could default to importing svelte/internal/track or something, which contains that line, but let people opt out

[irishburlybear]

If you want this it should be reversed. Opt everyone out. Let everyone know about it, have them decide to turn it on via a "do this for me, please ad campaign". It wouldn't hurt to maybe have a little carrot dangling on the other side. I do not know what that carrot would be. Maybe another feature of some sorts. I know this isn't the most powerful route. But. It is the most(ish) honorable / transparent.

[sbyware]

As a professional Pen. Tester / Red Team Operator, being able to view the SK ver. no. is a big thing, as it presents a more broad attack surface given the presence of (previously patched) vulnerability becoming exploitable due to a potentially out of date version of SK.

I say hide it, that's my two cents. It provides no usage to the end user so.

[ahme-dev]

@irishburlybear Don't other frameworks already expose that the site is running them by default? I don't see why Svelte doing it would not be quite honorable.

So, yes. I think the boolean with an opt-out is good.

[brandonmcconnell]

My initial thought was that something like this should def be an opt-in setting, but I see how that would remove most of the value here.

I guess the main thought I have is— what are the main downsides to doing this? Vulnerabilities if certain versions of Svelte/SvelteKit are exposed to be vulnerable to SSR attacks somehow? If that's not an issue and there isn't any risk involved, I don't immediately see any glaring issues with this, maybe exposing via the JS prop.

If there is risk, I wonder if there would be some sort of way to encrypt/hash it in a way that the svelte team can interpret but cannot be interpreted easily otherwise.

[korywka]

Isn't that a gift for vulnerabilities scanners?

[SarcevicAntonio]

Security by obscurity is generally not the way, but it does have some value here‽

I'd say expose usage of Svelte/Kit for everyone, version as opt in to be on the safe side.

[samal-rasmussen]

If you want this it should be reversed. Opt everyone out. Let everyone know about it, have them decide to turn it on via a "do this for me, please ad campaign". It wouldn't hurt to maybe have a little carrot dangling on the other side. I do not know what that carrot would be. Maybe another feature of some sorts. I know this isn't the most powerful route. But. It is the most(ish) honorable / transparent.

There's no reason to have this at all if it is opt in. Too few would use it, so it wouldn't be useful for statistics.

[TGlide]

I'd say stick with exposing a boolean. Exposing the version has much more to lose than to gain

[lucianoratamero]

also, if they could detect sveltekit apps using the css selector, is there a native and easy way to change the prefix for generated css classes?
because having a boolean for exposing the version sounds nice, but without having an option to change the prefix, it wouldn't be a complete solution, imo.

[paoloricciuti]

I think this can be beneficial and I'm with you guys to expose the boolean to prevent exposing potentially old and prepatched versions of websites.