I already have XSLT in my website because I have an Atom feed and XSLT is the only way to serve formatted Atom/RSS feeds in a static site. Perhaps you have never considered the idea that someone might want to purchase some cheap static hosting to serve their personal website, but it is a fine way to do things. This change pries the web ever further out of the hands of common people and into the big websites that just want the browser to serve their apps.
How do you intend to put PHP in an RSS document? If it serves an HTML one instead, then the RSS will no longer be available. You could try checking the HTTP headers to determine if the page is being fetched by an RSS reader or a browser, but such an approach is much more brittle than XSLT, which solves the problem exactly and easily. Not to mention it allows users to download browser extensions that override the provided formatting of XSLT documents with a custom standard one if they desire.
Not every application will set these correctly. It is less reliable than simply serving a static page. And that's the core of this issue. Before XSLT was removed, your website could be a directory of static content. You can put it in a zip file and send it anywhere you want. Now, even the most basic website (blog + feed) will require some dynamic content to work properly. We go from a world where static hosting is possible to one where it's less possible, and all because some browser implementors couldn't be bothered to upgrade a library to a safe version.
This would also break the workflow I have for my site, where I build it as a static directory locally during development and point Python's trivial HTTP server at it to access the content over localhost.
And it's totally insulting because the people removing this have created a (memory safe!) browser extension that lets you view XSLT documents, and put special logic in the browser to show users a message telling them to download that extension when an XSLT-styled document is loaded. They should bundle the extension with the browser instead of breaking my website and telling users where to fix it.
It's perfectly reasonable (and much more maintainable and powerful) to use client side JavaScript on a static site to transform Atom or RSS into HTML.
If your argument is that you don't want to use JavaScript because it's Turing complete and insecure and riddled with bugs and security holes, then why the fuck are you using XSLT?
RSS documents do not support JavaScript. Also, XSLT is not Turing complete as far as I know, though some implementations extend the spec to become Turing complete. Even if it is, a potentially Turing complete XSLT document does not present the same kinds of risks as JavaScript does. Do you think someone will be able to fingerprint your browser using XSLT? I'll file that under “highly unlikely”. Specter and meltdown also aren't exactly going to work in XSLT. There are memory-safe XSLT parsers available and existing parsers can be run in a memory-safe WASM sandbox, so that's not really a concern either.
But as you obviously know, HTML documents do support JavaScript, and there's no reason to link to a raw XML RSS or Atom document directly, so problem solved. If you're so cautious you refuse to enable JavaScript, then you have absolutely no justification for enabling XSLT.
Handwaving that vulnerabilities are "highly unlikely" is dangerous security theater. It doesn't matter how unlikely you guess and wish they are, they just have to be possible. And the fact that the XSLT 1.0 implementations built into browsers are antique un-sandboxed memory-unsafe C++ code make vulnerabilities "highly likely", not "highly unlikely", which the record clearly proves.
Browsers only natively support the ancient version of XSLT 1.0, so if you need a less antiquated version, you should use a modern memory safe sandboxed polyfill, or process it on the server side, or more safely not use XSLT at all and simply use JavaScript instead (simply transforming RSS to HTML directly with JavaScript is a MUCH smaller and harder attack surface than the massive overkill of including an entire sandboxed general purpose Turing complete XSLT processor), instead of foolishly relying on non-sandboxed old untrustworthy poorly maintained C++ code built into the browser.
Of course all versions of XSLT are Turing complete, as you can easily confirm on Wikipedia, and which is quite obvious if you have ever read the manual and used it. It has recursive template calls, conditionals, variables and parameters, pattern matching and selection, text and node construction, unbounded input and recursion depth, etc. So how could it possibly not be Turing complete, since it has the same expressive power of functional programming languages? And that should be quite obvious to anyone who knows XSLT and basic CS101, at a glance, without a formal proof.
>While XSLT was originally designed as a special-purpose language for XML transformation, the language is Turing-complete, making it theoretically capable of arbitrary computations.
Do you recall the title of Chrome's web page explaining why they're removing XSLT? "Removing XSLT for a more secure browser" (aka "Bin Ladin Determined To Strike in XSLT" ;). Didn't you read that article, and the recent HN discussion about it? You can't just claim nobody warned you, like GW Bush tried to do.
>The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. For example, security audits and bug trackers have repeatedly identified high-severity vulnerabilities in these parsers (e.g., CVE-2025-7425 and CVE-2022-22834, both in libxslt). Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. The security risks of maintaining this brittle, legacy functionality far outweighs its limited modern utility. [...]
Your overconfidence in XSLT's security in browsers is unjustified and unsupported by its track record and reputation, its complexity is extremely high, it's written in unsafe un-sandboxed C/C++, it gets vastly less attention and hardening and use than JavaScript, and its vulnerabilities are numerous and well documented.
Examples:
CVE‑2025‑7425: A heap use-after-free in libxslt caused by corruption of the attribute type (atype) flags during key() processing and tree-fragment generation. This corruption prevents proper cleanup of ID attributes, enabling memory corruption and possibly arbitrary code execution.
CVE‑2024‑55549: Another use-after-free in libxslt (specifically xsltGetInheritedNsList) disclosed via a Red Hat advisory.
CVE‑2022‑22834: An XSLT injection vulnerability in a commercial application (OverIT Geocall) allowing remote code execution from a “Test Trasformazione XSL” feature. Shows how XSLT engines/processors can be attack surfaces in practice.
CVE-2019-18197: (libxslt 1.1.33)
In the function xsltCopyText (file transform.c) a pointer variable isn’t reset in certain flows; if the memory area was freed and reused, a bounds check could fail and either write outside a buffer or disclose uninitialised memory.
CVE-2008-2935: buffer overflows in crypto.c for libexslt.
CVE-2019-5815: type confusion in xsltNumberFormatGetMultipleLevel, repeated memory safety flaws (heap/stack corruption, improper bounds checks, pointer reuse) in the library over many years.
>and there's no reason to link to a raw XML RSS or Atom document directly
What's the point of having an Atom feed if I can't give people a link to it? Do you just expect me to write “this website has an atom feed” and have only the <link> element invisibly pointing at it? That is terrible UX. And then what if I want to include a link to my feed in a message to share it with someone?
>Handwaving that vulnerabilities are "highly unlikely" is dangerous security theater
No it isn't. There are memory safe XSLT implementations. Not so for JavaScript. This is because XSLT is a simple language and JavaScript a complicated one. You are trying to make the case that XSLT is inherently unsafe because poor implementations of it exist, yet it is actually much safer because safe implementations exist and are easy to write. It can initiate no outgoing internet connections, cannot read from memory directly, cannot do any of the things that makes JavaScript inherently dangerous.
>simply transforming RSS to HTML directly with JavaScript is a MUCH smaller and harder attack surface than the massive overkill of including an entire sandboxed general purpose Turing complete XSLT processor
Firstly, you can't include JavaScript tags in RSS or Atom so my website would not conform to any web standard. Secondly, by using JavaScript, I'm demanding that my users enable a highly dangerous web feature that has been the basis for many attacks. By using XSLT, I'm giving them the option to use a much smaller interface with safer implementations available. How many CVEs have their been in JavaScript runtimes compared with XSLT? And finally, browser developers should just bundle one of these JavaScript polyfills and activate it for documents with stylesheets if they are so easy to use. Demanding that users deviate from web standards to get simple features like XML styling is ridiculous and it would clearly be little effort for them to silently append a polyfill script to documents with XSLT automatically. If that's the only way they can make it secure, that's what they should do.
>Your overconfidence in XSLT's security in browsers is unjustified and unsupported by its track record and reputation, its complexity is extremely high, it's written in unsafe un-sandboxed C/C++, it gets vastly less attention and hardening and use than JavaScript, and its vulnerabilities are numerous and well documented.
I have no confidence at all in browsers' implementations of XSLT because they admit they use a faulty library. I have absolute confidence that it would be little effort to replace the faulty library with a correct one, and that doing so would be miles safer than expecting users to enable JavaScript.
>Of course all versions of XSLT are Turing complete, as you can easily confirm on Wikipedia
Do not quote Wikipedia as a source. In this case, the provided source in the Wikipedia page claims only that version 2.0 is Turing complete, and this claim is erroneous, based on a proprietary extension of certain XSLT processors but not that used in Chrome.
It is quite frankly ridiculous to me that people are bending over backwards to suggest that XSLT is somehow an inherent security risk when you can include a JavaScript fragment in pages to trigger an XSLT processor. Whatever risk is posed by XSLT is a clear subset of that posed by JavaScript for this reason alone. You will never see a complete JavaScript implementation in XSLT because it isn't possible. One language is given greatly more privileged access to the resources and capabilities of the user's computer than the other.
The decision of web-browser to include faulty XSLT libraries when safe ones exist is the source of risk here, and not these same people who have been putting users at risk in a billion different ways over the years come to me and suggest that I have to remove a completely innocuous feature from my website and replace it with a more dangerous one while breaking standards compliance because they can't be bothered to switch from an unsafe implementation to a safe one.
