Any service that is exposed as a website that has data which you would like to keep secure = potentially hacked through attacks like these. It's usually not possible to choose to not have data available on internet connected services sadly.

Sandbox escapes are discovered all the time (pretty sure I've read about a few just this past week) and there are a lot of other problems CSS can enable (ads, fingerprinting, etc)

As a user: Browsers let you manually disable JS, but you can also use an extension such as NoScript (I do).

As a web developer: You can use Content Security Policy to limit or disable JS, as well as other resources such as CSS and images.

That's not relavent to the attack discussed in the article. These types of attacks do not involve javascript, nor could they due to the same origin policy.

Why on earth would you want to load JS before content is loaded but not after? If you are able to assemble the page based on data sources before loading the page, you can just server-render the damn thing and disable JS altogether?

JS is essential for polished UX when you have highly interactive components. Technically mapquest got server-rendered interactive maps working, but no one would choose that over the usability of Google Maps or OpenStreetMaps today

I've got noscript which at least keeps JS off by default and allows me to selectively enable scripts by domain. Now I just a similar tool for CSS. Something that whitelists a sane set of features that can't be used (at least as easily) for interactivity, ads, fingerprinting, and other malicious activity while letting me explicitly blacklist annoyances (like scrollbar styles or sticky headers). The way things are going I'll probably need something similar for HTML too.

Does JS protect against this particular attack? It seems like it's mostly implemented in CSS and SVG.

SVG and CSS filters can leak cross-origin data via iframes from March 6, 2025

Researchers have observed that, in Chrome:

A hostile webpage can create SVG or CSS filters that cover an iframe on the same page and act on the iframe's content.

Specially-crafted filters can be created that vary their performance characteristics (different use of memory bandwidth or compute resources) based on input data.

The induced differences in load can, in turn, be used to leak the input data through a timing sidechannel readable from Javascript.

It's easy to prevent clickjacking attacks by not allowing your website to be embedded in an iframe.

You can do that by either adding a header to your network requests, o̶r̶ ̶b̶y̶ ̶a̶d̶d̶i̶n̶g̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶m̶e̶t̶a̶ ̶t̶a̶g̶ ̶t̶o̶ ̶y̶o̶u̶r̶ ̶p̶a̶g̶e̶:̶

̶<̶m̶e̶t̶a̶ ̶h̶t̶t̶p̶-̶e̶q̶u̶i̶v̶=̶"̶X̶-̶F̶r̶a̶m̶e̶-̶O̶p̶t̶i̶o̶n̶s̶"̶ ̶c̶o̶n̶t̶e̶n̶t̶=̶"̶D̶E̶N̶Y̶"̶>̶

EDIT:

According to MDN, it will only work by adding it to your headers. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...