Trang này được dịch bởi Cloud Translation API.

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

Mason Freed

Dominik Röttsches

Ngày xuất bản: 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ả API JavaScript XSLTProcessor và chỉ dẫn xử lý biểu định kiểu XML. Chúng tôi dự định ngừng hỗ trợ từ phiên bản 155 (ngày 17 tháng 11 năm 2026). Các dự án Firefox và WebKit cũng cho biết kế hoạch xoá XSLT khỏi các 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ề lịch sử và bối cảnh, 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 một 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.

Tính năng nào sẽ bị xoá?

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

Lớp XSLTProcessor (ví dụ: new XSLTProcessor()).
Chỉ dẫn xử lý XSLT (ví dụ: <?xml-stylesheet … ?>).

Dòng thời gian cho Chrome

Chrome có kế hoạch sau:

Chrome 142 (ngày 28 tháng 10 năm 2025): Đã thêm thông báo sớm trên 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 chính thức API – 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 148 (Canary ngày 10 tháng 3 năm 2026): 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 152 (ngày 25 tháng 8 năm 2026): Bản dùng thử theo nguyên gốc (OT) và Chính sách doanh nghiệp (EP) sẽ được triển khai để thử nghiệm. Những tính năng này cho phép các trang web và doanh nghiệp tiếp tục sử dụng các tính năng sau ngày xoá.
Chrome 155 (ngày 17 tháng 11 năm 2026): XSLT 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, trừ những người tham gia Thử nghiệm nguồn gốc và Chính sách doanh nghiệp.**
Chrome 164 (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 ngừng hoạt động. XSLT bị vô hiệu hoá đố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 một 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) mà người dùng có thể hiển thị.

Ví dụ: một biểu định kiểu XSLT có thể nhận đầu vào XML sau:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

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

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="/page/message">
    <body>
      <p>Message: <xsl:value-of select="."/></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 chỉ thị xử lý XSL xuất hiện trong ví dụ trước, còn có API JavaScript XSLTProcessor. API này có thể dùng để xử lý các tài liệu XML cục bộ bằng các 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, làm ngôn ngữ để chuyển đổi tài liệu XML sang các định dạng khác, thường là HTML để hiển thị trong trình duyệt web. Trước đề xuất chính thức 1.0, Microsoft đã chủ động triển khai một giải pháp độc quyền dựa trên bản nháp của W3C trong Internet Explorer 5.0, được 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 cả Safari, Opera và Chrome sau này, cũng tích hợp bộ xử lý XSLT 1.0 gốc, giúp các hoạt động 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 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, trong đó giới thiệu các tính năng mạnh mẽ như biểu thức chính quy, các kiểu dữ liệu được cải thiện và khả năng xử lý JSON. Tuy nhiên, khả năng hỗ trợ của trình duyệt đã bị đình trệ. Ngày nay, tất cả các công cụ trình duyệt web chính chỉ cung cấp chế độ hỗ trợ gốc cho XSLT 1.0 ban đầu từ năm 1999. Sự thiếu tiến bộ này, cùng với sự gia tăng 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) cung cấp khả năng thao tác và tạo mẫu DOM 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 Flash trong trình duyệt web phần lớn đã được thay thế bằng những công nghệ dựa trên JavaScript này.

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 một 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 hoạt động chuyển đổi này, chẳng hạn như libxslt (do các trình duyệt Chromium sử dụng), là những cơ sở mã C/C++ phức tạp và cũ. Loại mã này rất dễ bị các lỗ hổng bảo mật bộ nhớ như tràn bộ nhớ đệm, có thể dẫn đến việc thực thi mã tuỳ ý. Ví dụ: các hoạt động kiểm tra bảo mật và trình theo dõi lỗi đã nhiều lần xác định các lỗ hổng có mức độ nghiêm trọng cao trong những trình phân tích cú pháp này (ví dụ: CVE-2025-7425 và CVE-2022-22834, cả hai đều nằm trong libxslt). Vì XSLT phía máy khách hiện là một tính năng hiếm khi được sử dụng, nên các thư viện này ít được bảo trì và kiểm tra bảo mật hơn nhiều so với các công cụ JavaScript cốt lõi, nhưng chúng lại là một bề mặt tấn công trực tiếp và mạnh mẽ để xử lý nội dung web không đáng tin cậy. Thật vậy, XSLT là nguồn gốc của một số lỗ hổng bảo mật tầm cỡ gần đây vẫn 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ị lỗi này lớn hơn nhiều so với tiện ích hiện đại hạn chế của chức năng này.

Hơn nữa, mục đích ban đầu của XSLT phía ứng dụng 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. Hoạt động phát triển web hiện đại dựa vào những thứ như Fetch API để truy xuất dữ liệu (thường là JSON) và DOMParser API để phân tích cú pháp an toàn các chuỗi XML hoặc HTML thành cấu trúc DOM trong hộp cát JavaScript bảo mật 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à những gì mà hầu hết các nhà phát triển web hiện đang sử dụng. Thật vậy, ngày 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 chỉ thị 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 xoá 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à xoá XSLT sẽ 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 những công nghệ thực sự hỗ trợ web hiện đại mà không làm mất khả năng thực tế của nhà phát triển.

Cải thiện tính 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. Đây là thư viện được dùng trong Chromium để phân tích cú pháp, tuần tự hoá và kiểm thử tính hợp lệ 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ế hoạt động 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ề bộ nhớ được viết bằng Rust. Điều quan trọng là chúng tôi sẽ không xoá XML khỏi trình duyệt; chỉ có XSLT được cân nhắc xoá ở đây. Chúng tôi dự định đả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.

Cách di chuyển

Có một số đường dẫn thay thế để di chuyển.

JSON

Đối với những 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 đã kết xuất xuống ứng dụng 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 số 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 cho Saxonica). Việc triển khai này vượt xa việc triển khai XSLT 1.0 trong trình duyệt web, triển khai 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 tiến hành.

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 giải pháp thay thế dựa trên WASM có chức năng được polyfill cho lớp XSLTProcessor, vì vậy, mã JavaScript hiện có có thể tiếp tục hoạt động như cũ:

<script src="xslt-polyfill.min.js"></script>

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

Polyfill cũng cung cấp một hàm tiện ích tự động để dễ dàng thay thế các tài liệu XML sử dụng chỉ thị xử lý XSLT:

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

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="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" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
   xmlns="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à chỉ dẫn 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, còn có một tiện ích Chrome mà bạn có thể thêm vào các trình duyệt được hỗ trợ. Tiện ích này sẽ áp dụng polyfill XSLT tương tự cho tất cả các trang XML thô có chứa chỉ thị xử lý XSLT hoặc các lệnh gọi đến XSLTProcessor. Bạn có thể dùng cách này cho các ứng dụng mà bạn không thể thay đổi XML hoặc XSLT nguồn để duy trì chức năng.

Cụ thể, khi XSLT bị vô hiệu hoá, Chrome hiện 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ề các 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 phương thức trong số đó, nhằm đề xuất các hướng đi cho những 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 để giúp nguồn cấp dữ liệu XML thô dễ đọ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ó 2 hướng giải quyết cho trường hợp sử dụng này. Cách "tiêu chuẩn" để thực hiện việc này bằng HTML 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 (người dùng nhìn thấy) 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 một tài nguyên XML. Điều này cũng tuân theo mô hình web thông thường rằng HTML dành cho con người và XML dành cho máy móc. Tất nhiên, cách 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 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ể tăng cường nguồn cấp dữ liệu RSS/Atom XML bằng một dòng, <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>, dòng này sẽ 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 đó sẽ 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.

Đầu ra 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ị trong số này 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 thành định dạng HTML mà con người có thể đọc được. Điều này cho phép bạn 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à một trường hợp sử dụng rất cụ thể cho ứng dụng, nên hình dạng của giải pháp có thể khác nhau. Đối với những ứng dụng mà mã nguồn của thiết bị nhúng có thể được cập nhật, mọi lựa chọn được mô tả trước đó (JSON, Polyfill) đều có thể hoạt động. Tuy nhiên, đặc biệt 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 đó, tiện ích có thể là lựa chọn tốt nhất, vì tiện ích này cho phép trình duyệt của ứng dụng tiếp tục đọc dữ liệu theo cách hoàn toàn giống nhau mà không cần sửa đổi thiết bị.

Tạo mẫu theo yêu cầu cho trang web

Đôi khi, nhà phát triển web 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 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ó lẽ chỉ là thêm polyfill để duy trì chức năng hiện có. Hoặc có thể thực hiện quá trình chuyển đổi XSLT ở phía máy chủ và phân phát HTML kết quả cho ứng dụng khách, thay vì XML thô. Giải pháp lâu dài hơn cho những thuộc tính như vậy là di chuyển sang một khung dựa trên JSON hoặc JavaScript hiện đại hơn.