Xoá XSLT để có một trình duyệt an toàn hơn

Mason Freed
Mason Freed
Dominik Röttsches
Dominik Röttsches

Ngày xuất bản: Ngày 29 tháng 10 năm 2025

Chrome dự định ngừng sử dụng và xoá XSLT khỏi trình duyệt. Tài liệu này trình bày chi tiết cách bạn có thể di chuyển mã trước khi xoá vào cuối năm 2026.

Chromium đã chính thức ngừng sử dụng XSLT, bao gồm cả XSLTProcessor JavaScript API và hướng dẫn xử lý XSLT. Chúng tôi dự định ngừng hỗ trợ từ phiên bản 158 (ngày 17 tháng 11 năm 2026). Các dự án Firefox và WebKit cũng đã cho biết kế hoạch loại bỏ XSLT khỏi công cụ trình duyệt của họ. Tài liệu này cung cấp một số thông tin về bối cảnh và lịch sử, giải thích cách chúng tôi xoá XSLT để giúp Chrome an toàn hơn, đồng thời cung cấp lộ trình di chuyển trước khi các tính năng này bị xoá khỏi trình duyệt. Để biết thông tin cập nhật mới nhất, hãy xem mục Trạng thái Nền tảng Chrome.

Nội dung nào sẽ bị xoá?

Có hai API trong trình duyệt triển khai XSLT và cả hai đều đang bị xoá:

Dòng thời gian cho Chrome

Chrome có kế hoạch như sau:

  • Chrome 142 (ngày 28 tháng 10 năm 2025): Thêm thông báo cảnh báo sớm trong bảng điều khiển vào Chrome.
  • Chrome 143 (ngày 2 tháng 12 năm 2025): Ngừng sử dụng API chính thức – thông báo cảnh báo ngừng sử dụng bắt đầu xuất hiện trong bảng điều khiển và trong Lighthouse.
  • Chrome 145 (ngày 2 tháng 12 năm 2025 Canary): Các bản phát hành Canary, Dev và Beta bắt đầu tắt XSLT theo mặc định, như một cảnh báo sớm.
  • Chrome 146 (ngày 10 tháng 3 năm 2026): Chính sách doanh nghiệp (EP) được triển khai để kiểm thử. Điều này cho phép các doanh nghiệp vừa thử nghiệm việc tắt XSLT sớm, vừa tiếp tục sử dụng các tính năng sau ngày tính năng bị gỡ bỏ.
  • Chrome 152 (ngày 25 tháng 8 năm 2026): Bản dùng thử theo nguyên gốc (OT) đã được triển khai để kiểm thử. Điều này cho phép các trang web tiếp tục sử dụng các tính năng sau ngày tính năng bị gỡ bỏ.
  • Chrome 154 (ngày 22 tháng 9 năm 2026): Các bản phát hành Canary, Dev và Beta của Webview bắt đầu tắt XSLT theo mặc định, như một cảnh báo sớm.
  • Chrome 158 (ngày 17 tháng 11 năm 2026): XSLT sẽ ngừng hoạt động trên các bản phát hành Ổn định, đối với tất cả người dùng ngoại trừ những người tham gia Bản dùng thử theo nguyên gốc và Chính sách doanh nghiệp.
  • Chrome 176 (ngày 17 tháng 8 năm 2027): Bản dùng thử theo nguyên gốc và Chính sách doanh nghiệp không còn hiệu lực. XSLT bị tắt đối với tất cả người dùng.

XSLT là gì?

XSLT (Extensible Stylesheet Language Transformations) là một ngôn ngữ dùng để chuyển đổi tài liệu XML, thường là sang các định dạng khác như HTML. Công cụ này sử dụng một tệp biểu định kiểu XSLT để xác định các quy tắc cho quá trình chuyển đổi này và một tệp XML chứa dữ liệu được dùng làm dữ liệu đầu vào.

Trong trình duyệt, khi nhận được một tệp XML liên kết đến biểu định kiểu XSLT, trình duyệt sẽ sử dụng các quy tắc trong biểu định kiểu đó để sắp xếp lại, định dạng và chuyển đổi dữ liệu XML thô thành một trang có cấu trúc (thường là HTML) có thể hiển thị cho người dùng.

Ví dụ: một biểu định kiểu XSLT có thể lấy dữ liệu đầu vào XML sau:

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
 me>s<sage
>  Hello World.
 /message
/page

và biểu định kiểu XSL này:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
  xsl:output meth>od=<"html"/
  xsl:template m>atch=<&quo>t;/page</>message&q<uot;
    body
      pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
 >   /body
  /xsl:template
/xsl:stylesheet

và xử lý chúng thành HTML này để trình duyệt hiển thị: HTML

<body>
  <p>Message: Hello World.</p>
</body>

Ngoài hướng dẫn xử lý XSL trong ví dụ trước, còn có API JavaScript XSLTProcessor có thể dùng để xử lý tài liệu XML cục bộ bằng biểu định kiểu XSLT cục bộ.

Lịch sử của XSLT

XSLT được World Wide Web Consortium (W3C) đề xuất vào ngày 16 tháng 11 năm 1999, dưới dạng một ngôn ngữ để chuyển đổi tài liệu XML sang các định dạng khác, phổ biến nhất là HTML để hiển thị trong trình duyệt web. Trước khi có đề xuất chính thức về phiên bản 1.0, Microsoft đã sớm chủ động cung cấp một phương thức triển khai độc quyền dựa trên bản nháp hoạt động của W3C trong Internet Explorer 5.0, phát hành vào tháng 3 năm 1999. Theo tiêu chuẩn chính thức, Mozilla đã triển khai tính năng hỗ trợ XSLT 1.0 gốc trong Netscape 6 vào cuối năm 2000. Các trình duyệt chính khác, bao gồm Safari, Opera và Chrome sau này, cũng tích hợp bộ xử lý XSLT 1.0 gốc, giúp việc chuyển đổi XML sang HTML phía máy khách trở thành một công nghệ web khả thi vào đầu những năm 2000.

Bản thân ngôn ngữ XSLT vẫn tiếp tục phát triển, với việc phát hành XSLT 2.0 vào năm 2007 và XSLT 3.0 vào năm 2017, giới thiệu các tính năng mạnh mẽ như biểu thức chính quy, kiểu dữ liệu cải tiến và khả năng xử lý JSON. Tuy nhiên, khả năng hỗ trợ của trình duyệt lại bị đình trệ. Hiện nay, tất cả các công cụ trình duyệt web chính chỉ hỗ trợ gốc cho XSLT 1.0 ban đầu từ năm 1999. Sự thiếu tiến bộ này, kết hợp với sự gia tăng của việc sử dụng JSON làm định dạng truyền dữ liệu, cũng như các thư viện và khung JavaScript (như jQuery, React và Vue.js) mang đến khả năng thao tác DOM và tạo mẫu linh hoạt và mạnh mẽ hơn, đã dẫn đến sự sụt giảm đáng kể trong việc sử dụng XSLT phía máy khách. Vai trò của ngôn ngữ này trong trình duyệt web phần lớn đã bị các công nghệ dựa trên JavaScript này thế chỗ.

Tại sao cần phải xoá XSLT?

Việc tiếp tục đưa XSLT 1.0 vào trình duyệt web gây ra rủi ro bảo mật đáng kể và không cần thiết. Các thư viện cơ bản xử lý những quá trình chuyển đổi này, chẳng hạn như libxslt (được các trình duyệt Chromium sử dụng), là toàn bộ mã nguồn C/C++ phức tạp và cũ kỹ. Loại mã này có tiếng là dễ mắc các lỗ hổng bảo mật liên quan đến an toàn bộ nhớ như tràn vùng đệm, có thể dẫn đến việc thực thi mã tuỳ ý. Ví dụ: các quy trình kiểm tra bảo mật và trình theo dõi lỗi đã nhiều lần xác định được các lỗ hổng bảo mật nghiêm trọng trong các trình phân tích cú pháp này (ví dụ: CVE-2025-7425 và CVE-2022-22834, cả hai đều trong libxslt). Vì XSLT phía máy khách hiện là một tính năng chuyên biệt và ít được sử dụng nên các thư viện này ít được bảo trì và rà soát bảo mật hơn nhiều so với các công cụ JavaScript cốt lõi. Tuy nhiên, chúng lại là một bề mặt tấn công trực tiếp và đầy rủi ro khi xử lý nội dung trên web không đáng tin cậy. Quả thực, XSLT là nguồn gốc gây ra một số vụ khai thác lỗ hổng bảo mật nghiêm trọng gần đây vốn đang tiếp tục gây rủi ro cho người dùng trình duyệt. Rủi ro bảo mật khi duy trì chức năng cũ, dễ bị tấn công này vượt xa lợi ích hạn chế mà nó mang lại trong thời đại hiện nay.

Hơn nữa, mục đích ban đầu của XSLT phía máy khách (chuyển đổi dữ liệu thành HTML có thể kết xuất) đã được thay thế bằng các API JavaScript an toàn hơn, tiện dụng hơn và được duy trì tốt hơn. Quá trình phát triển web hiện đại dựa vào những yếu tố như Fetch API để truy xuất dữ liệu (thường là JSON) và DOMParser API để phân tích cú pháp chuỗi XML hoặc HTML một cách an toàn vào cấu trúc DOM trong hộp cát JavaScript an toàn của trình duyệt. Sau đó, các khung như React, Vue và Svelte sẽ quản lý việc kết xuất dữ liệu này một cách hiệu quả và an toàn. Chuỗi công cụ hiện đại này đang được phát triển tích cực, hưởng lợi từ khoản đầu tư lớn vào bảo mật trong các công cụ JavaScript và là công cụ mà hầu như tất cả các nhà phát triển web đều sử dụng hiện nay. Thật vậy, hiện nay chỉ có khoảng 0,02% số lượt tải trang web thực sự sử dụng XSLT, trong đó chưa đến 0,001% sử dụng hướng dẫn xử lý XSLT.

Đây không phải là hành động chỉ dành cho Chrome hoặc Chromium: hai công cụ trình duyệt chính khác cũng hỗ trợ việc loại bỏ XSLT khỏi nền tảng web: WebKit, Gecko.

Vì những lý do này, việc ngừng sử dụng và loại bỏ XSLT sẽ giúp giảm bề mặt tấn công của trình duyệt cho tất cả người dùng, đơn giản hoá nền tảng web và cho phép các tài nguyên kỹ thuật tập trung vào việc bảo mật các công nghệ thực sự hỗ trợ web hiện đại mà không làm mất đi khả năng thực tế của nhà phát triển.

Cải thiện khả năng bảo mật khi phân tích cú pháp XML

Tương tự như các vấn đề bảo mật nghiêm trọng trong libxslt, các vấn đề bảo mật nghiêm trọng gần đây đã được báo cáo đối với libxml2, được dùng trong Chromium để phân tích cú pháp, chuyển đổi tuần tự và kiểm tra tính đúng dạng của XML. Để giải quyết các vấn đề bảo mật trong tương lai liên quan đến việc phân tích cú pháp XML trong Chromium, chúng tôi dự định loại bỏ dần việc sử dụng libxml2 và thay thế việc phân tích cú pháp XML bằng một thư viện phân tích cú pháp XML an toàn với bộ nhớ được viết bằng Rust. Quan trọng là chúng tôi sẽ không xoá XML khỏi trình duyệt; chỉ có XSLT đang được xem xét để xoá tại đây. Chúng tôi muốn đảm bảo rằng việc thay thế libxml2 hoàn toàn minh bạch đối với các nhà phát triển web.

XML + CSS không bị xoá

Điều quan trọng là phải phân biệt việc ngừng sử dụng XSLT (<?xml-stylesheet type="text/xsl" ... ?>) với chính lệnh xử lý <?xml-stylesheet ... ?>, lệnh này vẫn được hỗ trợ khi dùng với CSS. Bạn vẫn có thể sử dụng lệnh xử lý bằng type="text/css" để áp dụng các quy tắc thiết kế và bố cục chuẩn cho dữ liệu thô, giống như cách bạn có thể làm với HTML. Ví dụ:

<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
  itemContent here/item
/root

Cách di chuyển

Có một số cách khác để di chuyển.

JSON

Đối với các trang web được xây dựng hoàn toàn trên XML và XSL, không có cách nào phù hợp với tất cả để thực hiện quá trình chuyển đổi. Các lựa chọn di chuyển bao gồm việc di chuyển quy trình xử lý XSLT sang phía máy chủ và gửi HTML được kết xuất xuống máy khách, hoặc di chuyển các điểm cuối API XML phía máy chủ sang JSON và thực hiện kết xuất phía máy khách bằng JavaScript để chuyển đổi JSON thành HTML DOM và CSS.

XSLT phía máy khách trong JavaScript

Có một vài thư viện XSLT phía máy khách (dựa trên JavaScript), nhưng thư viện lớn nhất cho đến nay là do Saxonica sản xuất (xem tài liệu toàn diện về Saxonica). Cách triển khai này vượt trội hơn hẳn so với cách triển khai XSLT 1.0 trong trình duyệt web, hỗ trợ đầy đủ cho tiêu chuẩn v3.0 mới nhất và cuối cùng là tiêu chuẩn v4.0 đang được phát triển.

Polyfill

Có một polyfill cố gắng cho phép mã hiện có (phụ thuộc vào việc triển khai XSLT 1.0 của trình duyệt web) tiếp tục hoạt động, trong khi không sử dụng các tính năng XSLT gốc của trình duyệt. Polyfill nằm trên GitHub.

Polyfill chứa một thay thế polyfill dựa trên WASM cho lớp XSLTProcessor, vì vậy, mã JavaScript hiện có có thể tiếp tục hoạt động như hiện tại:

<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt

script
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, d<ocument>);
/script

Polyfill cũng cung cấp một hàm hiệu dụng tự động để dễ dàng thay thế các tài liệu XML sử dụng hướng dẫn xử lý XSLT:

Đối với tệp demo.xml gốc như sau:

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...

Bạn có thể thêm một dòng để gọi polyfill và chuyển đổi tài liệu bằng biểu định kiểu XSLT được tham chiếu:

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
   xml>ns="http://www.w3.org/1999/xhtml"/script
...content...

Trong trường hợp này, phần tử <script> mới sẽ tải polyfill, phát hiện loại tài liệu XML và lệnh xử lý XSLT, đồng thời tải tài liệu đó một cách minh bạch, thay thế tài liệu.

Phần mở rộng

Ngoài ra, bạn có thể thêm một tiện ích Chrome vào các trình duyệt được hỗ trợ. Tiện ích này sẽ áp dụng cùng một polyfill XSLT cho tất cả các trang XML thô chứa hướng dẫn xử lý XSLT hoặc lệnh gọi đến XSLTProcessor. Bạn có thể sử dụng chính sách này cho những ứng dụng không thể thay đổi XML hoặc XSLT nguồn để duy trì chức năng.

Cụ thể, khi XSLT bị tắt, Chrome hiện sẽ hiển thị một biểu ngữ cảnh báo liên kết trực tiếp đến trang tìm kiếm tiện ích, để giúp người dùng tìm thấy tiện ích:

Thông báo xuất hiện trong Chrome khi phát hiện thấy xslt.

Các trường hợp sử dụng cụ thể

Trong cuộc thảo luận về tiêu chuẩn HTML, một số trường hợp sử dụng cụ thể đã được xác định. Phần này nói cụ thể về từng lựa chọn để đề xuất hướng đi cho các nhà phát triển đang xuất bản tài nguyên XML sử dụng XSLT.

Nguồn cấp dữ liệu RSS và Atom

Trong nhiều nguồn cấp dữ liệu RSS hoặc Atom hiện có, XSLT được dùng để chuyển đổi nguồn cấp dữ liệu XML thô thành định dạng mà con người có thể đọc được khi xem trực tiếp trong trình duyệt. Trường hợp sử dụng chính là khi người dùng vô tình nhấp vào đường liên kết đến nguồn cấp dữ liệu RSS của một trang web, thay vì dán đường liên kết đó vào trình đọc RSS, họ sẽ nhận được một phản hồi HTML được định dạng mà họ có thể đọc, thay vì chính XML thô.

Có hai hướng giải quyết cho trường hợp sử dụng này. Cách "chuẩn" trong HTML để thực hiện việc này là thêm <link rel="alternate" type="application/rss+xml"> vào một trang web (dựa trên HTML), thay vì thêm một <a href="something.xml"> rõ ràng (hiển thị với người dùng) mà người dùng có thể vô tình nhấp vào. Giải pháp này cho phép trình đọc RSS tìm thấy nguồn cấp dữ liệu nếu người dùng chỉ dán URL của trang web, nhưng cũng cho phép người dùng là con người xem nội dung HTML thông thường mà không bị nhầm lẫn bởi đường liên kết đến tài nguyên XML. Điều này cũng tuân theo mô hình web thông thường, trong đó HTML dành cho con người và XML dành cho máy móc. Tất nhiên, điều này không giải quyết được trường hợp người dùng chỉ "có" một đường liên kết RSS từ đâu đó và họ dán đường liên kết đó vào trình duyệt web (thay vì trình đọc RSS).

Khi không muốn sử dụng giải pháp đó, polyfill sẽ cung cấp một đường dẫn khác. Như đã đề cập trước đó, bạn có thể bổ sung một dòng <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> vào nguồn cấp dữ liệu XML RSS/Atom để duy trì hành vi hiện tại của quá trình chuyển đổi dựa trên XSLT sang HTML. Điều này không ảnh hưởng đến khả năng tiếp tục phân tích cú pháp XML của trình đọc RSS, vì <script> là phần tử con trực tiếp của phần tử gốc.

Kết quả API cho thiết bị nhúng

Một số thiết bị nhúng thương mại đo lường hoặc tạo dữ liệu XML để người dùng sử dụng trên mạng cục bộ. Một số thiết bị thực hiện việc này bằng cách tạo một nguồn cấp dữ liệu XML duy nhất sử dụng XSLT để chuyển đổi nguồn cấp dữ liệu đó thành định dạng HTML mà con người có thể đọc được. Điều này cho phép xem trực tiếp API trong trình duyệt mà không cần thêm mã trên thiết bị hoặc trong trình duyệt.
Vì đây là trường hợp sử dụng rất cụ thể cho ứng dụng, nên hình thức của giải pháp có thể khác nhau. Đối với các ứng dụng có thể cập nhật mã nguồn của thiết bị nhúng, bạn có thể sử dụng bất kỳ lựa chọn nào được mô tả trước đó (JSON, Polyfill). Tuy nhiên, cụ thể là nhiều thiết bị như vậy rất khó hoặc không thể cập nhật vì nhiều lý do. Trong trường hợp đó, phần mở rộng có thể là lựa chọn tốt nhất, vì phần mở rộng này cho phép trình duyệt của ứng dụng khách tiếp tục đọc dữ liệu theo cùng một cách mà không cần sửa đổi thiết bị.

Tạo mẫu từng phần cho trang web

Nhà phát triển web đôi khi sử dụng XSLT ở phía máy khách để áp dụng mã đánh dấu trình bày cho mã đánh dấu ngữ nghĩa, hoạt động như một ngôn ngữ tạo mẫu lười biếng tách biệt với hệ sinh thái JavaScript.

Có hai giải pháp cho vấn đề chung này. Đối với một trang web hiện có được xây dựng theo cách này, giải pháp dễ nhất có thể chỉ là thêm polyfill để duy trì chức năng hiện có. Hoặc có thể thực hiện phép biến đổi XSLT ở phía máy chủ và phân phát HTML thu được cho ứng dụng khách, thay vì XML thô. Giải pháp lâu dài hơn cho các tài sản như vậy là di chuyển sang một khung JavaScript hoặc JSON hiện đại hơn.

Nếu bạn gặp một vấn đề cụ thể trong Chrome liên quan đến việc ngừng sử dụng XSLT này, hãy báo cáo lỗi tại đây.

Cách phát hiện việc sử dụng XSLT

Nhìn chung, bạn có thể phát hiện các tính năng không dùng nữa (chẳng hạn như XSLT) trong toàn bộ mã nguồn của mình theo một số cách. Phần này trình bày hai trong số các phương pháp đó.

API Báo cáo

Reporting API là một cơ chế báo cáo chung để các ứng dụng web sử dụng báo cáo về nhiều tính năng và điều kiện của nền tảng, bao gồm cả việc ngừng sử dụng tính năng. Để thiết lập báo cáo về việc ngừng sử dụng XSLT, bạn có thể sử dụng một đoạn mã như sau:

new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    if (report.body.id === "XSLT") {
      // XSLT usage was detected - report it back here.
    }
  });
}, {types: ["deprecation"],buffered: true}).observe();

Xem mã này hoạt động trên CodePen.

Báo cáo công nghệ cũ của doanh nghiệp

Đối với quản trị viên của một doanh nghiệp, bạn có thể sử dụng Báo cáo công nghệ cũ để tự động thu thập thông tin về việc sử dụng tính năng không dùng nữa và báo cáo lại theo cách thân thiện với người dùng. Hãy xem bài viết này trên trang web của Nhóm hỗ trợ Google để biết thêm thông tin về cách bật tính năng này.