Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

더 안전한 브라우저를 위해 XSLT 삭제

Mason Freed

Dominik Röttsches

게시일: 2025년 10월 29일

Chrome은 브라우저에서 XSLT를 지원 중단하고 삭제할 예정입니다. 이 문서에서는 2026년 말에 삭제되기 전에 코드를 이전하는 방법을 자세히 설명합니다.

Chromium은 XSLTProcessor JavaScript API 및 XSLT 처리 안내를 포함한 XSLT를 공식적으로 지원 중단했습니다. 버전 158(2026년 11월 17일)부터 지원을 중단할 예정입니다. Firefox 및 WebKit 프로젝트에서도 브라우저 엔진에서 XSLT를 삭제할 계획을 밝혔습니다. 이 문서에서는 Chrome을 더 안전하게 만들기 위해 XSLT를 삭제하는 방법을 설명하고, 이러한 기능이 브라우저에서 삭제되기 전에 이전할 수 있는 경로를 제공합니다. 최신 업데이트는 Chrome 플랫폼 상태 항목을 참고하세요.

무엇이 삭제되나요?

브라우저에는 XSLT를 구현하는 두 가지 API가 있으며, 둘 다 삭제됩니다.

XSLTProcessor 클래스(예: new XSLTProcessor())
XSLT 처리 명령어(예: <?xml-stylesheet type="text/xsl" ... ?>)

Chrome 타임라인

Chrome의 계획은 다음과 같습니다.

Chrome 142(2025년 10월 28일): 조기 경고 콘솔 메시지가 Chrome에 추가됩니다.
Chrome 143(2025년 12월 2일): API의 공식 지원 중단 - 지원 중단 경고 메시지가 콘솔과 Lighthouse에 표시되기 시작합니다.
Chrome 145(2025년 12월 2일 Canary): Canary, Dev, 베타 버전에서 조기 경고로 기본적으로 XSLT를 사용 중지하기 시작합니다.
Chrome 146(2026년 3월 10일): 테스트를 위해 엔터프라이즈 정책(EP)이 시작됩니다. 이를 통해 기업은 XSLT 사용 중지를 조기에 테스트할 수 있으며 삭제 예정일 이후에도 기능을 계속 사용할 수 있습니다.
Chrome 152(2026년 8월 25일): 오리진 트라이얼(OT) 테스트가 시작됩니다. 이를 통해 사이트는 기능 삭제 예정일 이후에도 해당 기능을 계속 사용할 수 있습니다.
Chrome 154(2026년 9월 22일): Webview Canary, Dev, 베타 버전에서 조기 경고로 기본적으로 XSLT를 사용 중지하기 시작합니다.
Chrome 158(2026년 11월 17일): 오리진 트라이얼 및 엔터프라이즈 정책 참여자를 제외한 모든 사용자의 안정화 버전에서 XSLT 기능이 작동 중지됩니다.
Chrome 176(2027년 8월 17일): 오리진 트라이얼 및 엔터프라이즈 정책이 작동 중지됩니다. 모든 사용자에 대해 XSLT가 사용 중지됩니다.

XSLT란 무엇인가요?

XSLT(Extensible Stylesheet Language Transformations)는 XML 문서를 HTML과 같은 다른 형식으로 변환하는 데 사용되는 언어입니다. XSLT 스타일시트 파일을 사용하여 이 변환의 규칙을 정의하고 입력으로 사용되는 데이터가 포함된 XML 파일을 사용합니다.

브라우저에서 XSLT 스타일시트에 연결되는 XML 파일을 수신하면 브라우저는 해당 스타일시트의 규칙을 사용하여 원시 XML 데이터를 재정렬, 형식 지정, 변환하여 사용자에게 렌더링할 수 있는 구조화된 페이지(일반적으로 HTML)로 만듭니다.

예를 들어 XSLT 스타일시트는 다음 XML 입력을 사용할 수 있습니다.

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

이 XSL 스타일시트:

<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

브라우저가 표시할 수 있도록 HTML로 처리합니다. HTML

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

이전 예시에 표시된 XSL 처리 안내 외에도 로컬 XSLT 스타일시트로 로컬 XML 문서를 처리하는 데 사용할 수 있는 XSLTProcessor JavaScript API도 있습니다.

XSLT의 역사

XSLT는 1999년 11월 16일에 월드 와이드 웹 컨소시엄(W3C)에서 XML 문서를 다른 형식(가장 일반적으로 웹브라우저에 표시하기 위한 HTML)으로 변환하는 언어로 권장되었습니다. 공식 1.0 권장사항이 나오기 전에 Microsoft는 1999년 3월에 출시된 Internet Explorer 5.0에서 W3C 작업 초안을 기반으로 한 독점 구현을 제공하여 초기 이니셔티브를 취했습니다. 공식 표준에 따라 Mozilla는 2000년 말 Netscape 6에서 네이티브 XSLT 1.0 지원을 구현했습니다. Safari, Opera, 이후의 Chrome을 비롯한 다른 주요 브라우저도 네이티브 XSLT 1.0 프로세서를 통합하여 2000년대 초에 클라이언트 측 XML-HTML 변환을 실행 가능한 웹 기술로 만들었습니다.

XSLT 언어 자체는 계속 발전하여 2007년에 XSLT 2.0, 2017년에 XSLT 3.0이 출시되었으며, 정규 표현식, 개선된 데이터 유형, JSON 처리 기능과 같은 강력한 기능이 도입되었습니다. 하지만 브라우저 지원은 정체되었습니다. 현재 모든 주요 웹브라우저 엔진은 1999년의 원래 XSLT 1.0에 대한 기본 지원만 제공합니다. 하지만 이후 XSLT의 발전은 정체되었고, JSON이 유선 형식으로 사용되기 시작했으며, 더욱 유연하고 강력한 DOM 조작 및 템플릿을 제공하는 JavaScript 라이브러리 및 프레임워크(예: jQuery, React, Vue.js)가 등장하면서 클라이언트 측 XSLT 사용이 크게 감소했습니다. 웹브라우저 내에서의 역할은 이러한 JavaScript 기반 기술로 대부분 대체되었습니다.

XSLT를 삭제해야 하는 이유는 무엇인가요?

웹브라우저에 XSLT 1.0이 계속 포함되면 심각하고 불필요한 보안 위험이 발생합니다. 이러한 변환을 처리하는 기본 라이브러리(예: Chromium 브라우저에서 사용하는 libxslt)는 복잡하고 오래된 C/C++ 코드베이스입니다. 이러한 유형의 코드는 버퍼 오버플로와 같은 메모리 안전 취약점에 특히 취약하며 이는 임의 코드 실행으로 이어질 수 있습니다. 예를 들어 보안 감사 및 버그 추적기에서 이러한 파서의 심각도가 높은 취약점을 반복적으로 식별했습니다(예: libxslt의 CVE-2025-7425 및 CVE-2022-22834). 클라이언트 측 XSLT는 이제 거의 사용되지 않는 틈새 기능이 되었기 때문에, 이러한 라이브러리는 핵심 JavaScript 엔진에 비해 유지 관리 및 보안 검토가 자주 실행되지 않습니다. 따라서 신뢰할 수 없는 웹 콘텐츠를 처리하는 데 있어 직접적이고 강력한 공격 표면을 제공합니다. 실제로 XSLT는 최근 여러 건의 심각한 보안 취약점 공격을 받았으며, 이로 인해 브라우저 사용자들이 여전히 위험에 처해 있습니다. 이 취약한 기존 기능을 유지하는 데 따른 보안 위험은 제한적인 현대적 유용성보다 훨씬 큽니다.

또한 데이터를 렌더링 가능한 HTML로 변환하는 클라이언트 측 XSLT의 원래 목적은 더 안전하고 인체공학적이며 유지관리가 더 잘되는 JavaScript API로 대체되었습니다. 최신 웹 개발은 데이터를 가져오는 Fetch API(일반적으로 JSON)와 브라우저의 안전한 JavaScript 샌드박스 내에서 XML 또는 HTML 문자열을 DOM 구조로 안전하게 파싱하는 DOMParser API와 같은 요소에 의존합니다. React, Vue, Svelte와 같은 프레임워크는 이 데이터의 렌더링을 효율적이고 안전하게 관리합니다. 이 최신 도구 모음은 활발하게 개발되고 있으며 JavaScript 엔진에 대한 대규모 보안 투자의 이점을 누리고 있으며, 오늘날 사실상 모든 웹 개발자가 사용하고 있습니다. 실제로 현재 웹페이지 로드의 약 0.02%만 XSLT를 사용하며, 0.001% 미만이 XSLT 처리 안내를 사용합니다.

이는 Chrome 또는 Chromium 전용 작업이 아닙니다. 다른 두 주요 브라우저 엔진도 웹 플랫폼에서 XSLT를 삭제하는 것을 지원합니다. WebKit, Gecko

이러한 이유로 XSLT를 지원 중단하고 삭제하면 모든 사용자의 브라우저 공격 표면이 줄어들고, 웹 플랫폼이 간소화되며, 개발자의 기능 손실 없이 최신 웹을 실제로 구동하는 기술을 보호하는 데 엔지니어링 리소스를 집중할 수 있습니다.

XML 파싱 보안 개선

libxslt의 심각한 보안 문제와 마찬가지로, XML의 올바른 형식 여부를 파싱, 직렬화, 테스트하기 위해 Chromium에서 사용되는 libxml2에 대해 심각한 보안 문제가 최근에 보고되었습니다. Chromium의 XML 파싱과 관련된 향후 보안 문제를 해결하기 위해 libxml2 사용을 단계적으로 중단하고 XML 파싱을 Rust로 작성된 메모리 안전 XML 파싱 라이브러리로 대체할 계획입니다. 중요한 점은 브라우저에서 XML을 삭제하지 않는다는 것입니다. 여기서는 XSLT만 삭제 대상으로 고려됩니다. libxml2를 대체하는 과정이 웹 개발자에게 완전히 투명하게 공개되도록 할 계획입니다.

XML + CSS가 삭제되지 않음

XSLT (<?xml-stylesheet type="text/xsl" ... ?>)의 지원 중단과 <?xml-stylesheet ... ?> 처리 명령 자체를 구분하는 것이 중요합니다. 처리 명령은 CSS와 함께 사용할 때 계속 지원됩니다. HTML과 마찬가지로 type="text/css"과 함께 처리 명령어를 사용하여 원시 데이터에 표준 레이아웃 및 디자인 규칙을 적용할 수 있습니다. 예를 들면 다음과 같습니다.

<?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

마이그레이션 방법

이전에는 몇 가지 대체 경로가 있습니다.

JSON

XML 및 XSL을 기반으로 완전히 구축된 사이트의 경우 전환을 위한 일률적인 방법은 없습니다. 마이그레이션 옵션에는 XSLT 처리 파이프라인을 서버 측으로 이동하고 렌더링된 HTML을 클라이언트로 전송하거나 서버 측 XML API 엔드포인트를 JSON으로 마이그레이션하고 JavaScript를 사용하여 JSON을 HTML DOM 및 CSS로 변환하는 클라이언트 측 렌더링을 수행하는 것이 포함됩니다.

JavaScript의 클라이언트 측 XSLT

사용 가능한 클라이언트 측(JavaScript 기반) XSLT 라이브러리가 몇 가지 있지만, 가장 큰 라이브러리는 Saxonica에서 제작한 것입니다(Saxonica에 대한 포괄적인 문서 참조). 이 구현은 웹브라우저의 XSLT 1.0 구현을 훨씬 뛰어넘어 최신 v3.0 표준과 진행 중인 v4.0 표준을 완벽하게 지원합니다.

폴리필

웹 브라우저의 XSLT 1.0 구현에 의존하는 기존 코드가 브라우저의 네이티브 XSLT 기능을 사용하지 않고도 계속 작동할 수 있도록 하는 폴리필이 있습니다. 폴리필은 GitHub에 있습니다.

폴리필에는 XSLTProcessor 클래스를 위한 기능적인 WASM 기반 폴리필 대체가 포함되어 있으므로 기존 JavaScript 코드가 그대로 계속 작동할 수 있습니다.

<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

또한 폴리필은 XSLT 처리 명령어를 사용하는 XML 문서를 쉽게 대체할 수 있는 자동 유틸리티 함수를 제공합니다.

다음과 같은 원본 demo.xml 파일의 경우:

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

한 줄을 추가하여 폴리필을 호출하고 참조된 XSLT 스타일시트로 문서를 변환할 수 있습니다.

<?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...

이 경우 새 <script> 요소는 폴리필을 로드하여 XML 문서 유형과 XSLT 처리 명령어를 감지하고 투명하게 로드하여 문서를 대체합니다.

확장 프로그램

지원되는 브라우저에 추가할 수 있는 Chrome 확장 프로그램도 있습니다. 이 확장 프로그램은 XSLT 처리 안내 또는 XSLTProcessor 호출이 포함된 모든 원시 XML 페이지에 동일한 XSLT 폴리필을 적용합니다. 이는 소스 XML 또는 XSLT를 변경할 수 없는 애플리케이션에서 기능을 유지하는 데 사용할 수 있습니다.

특히 XSLT가 사용 중지되면 Chrome에 확장 프로그램 검색 페이지로 직접 연결되는 경고 배너가 표시되어 사용자가 확장 프로그램을 찾는 데 도움이 됩니다.

xslt가 감지되면 Chrome에 표시되는 메시지입니다.

구체적인 사용 사례

HTML 표준에 관한 토론에서 몇 가지 구체적인 사용 사례가 확인되었습니다. 이 섹션에서는 현재 XSLT를 사용하는 XML 리소스를 게시하는 개발자에게 권장되는 경로를 제시하기 위해 각 항목에 대해 구체적으로 설명합니다.

RSS 및 Atom 피드

기존의 많은 RSS 또는 Atom 피드에서 XSLT는 브라우저에서 직접 볼 때 원시 XML 피드를 사람이 읽을 수 있도록 만드는 데 사용됩니다. 기본 사용 사례는 사용자가 실수로 사이트의 RSS 피드 링크를 클릭했을 때 해당 링크를 RSS 리더에 붙여넣는 대신 원시 XML 자체가 아닌 읽을 수 있는 형식의 HTML 응답을 받는 것입니다.

이 사용 사례에는 두 가지 방법이 있습니다. 이를 위한 '표준' HTML 방식은 사용자가 의도하지 않은 클릭을 할 수 있는 명시적인(사용자에게 표시되는) <a href="something.xml">를 추가하는 대신 (HTML 기반) 사이트에 <link rel="alternate" type="application/rss+xml">를 추가하는 것입니다. 이 솔루션을 사용하면 사용자가 웹사이트 URL만 붙여넣어도 RSS 리더가 피드를 찾을 수 있으며, XML 리소스 링크로 인해 혼동하지 않고 일반 HTML 콘텐츠를 볼 수 있습니다. 이는 HTML은 인간을 위한 것이고 XML은 머신을 위한 것이라는 일반적인 웹 패러다임을 따릅니다. 물론 이 방법은 사용자가 어딘가에서 RSS 링크를 '가져와' RSS 리더가 아닌 웹브라우저에 붙여넣는 경우에는 해결되지 않습니다.

이 솔루션을 원하지 않는 경우 폴리필은 다른 경로를 제공합니다. 앞서 언급했듯이 RSS/Atom XML 피드는 <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> 한 줄로 보강할 수 있으며, 이를 통해 XSLT 기반 HTML 변환의 기존 동작을 유지할 수 있습니다. <script>는 루트 요소의 직접 하위 요소이므로 RSS 리더가 XML을 계속 파싱하는 기능에는 영향을 미치지 않습니다.

임베디드 기기용 API 출력

일부 상용 임베디드 기기는 로컬 네트워크의 사용자가 사용할 수 있도록 XML 데이터를 측정하거나 생성합니다. 이러한 기기 중 일부는 XSLT를 사용하여 인간이 읽을 수 있는 HTML 형식으로 변환하는 단일 XML 데이터 피드를 생성하여 이 작업을 수행합니다. 이렇게 하면 기기나 브라우저에 추가 코드가 없어도 브라우저에서 API를 직접 볼 수 있습니다.
이는 애플리케이션별 사용 사례이므로 솔루션의 형태가 다를 수 있습니다. 삽입된 기기의 소스 코드를 업데이트할 수 있는 애플리케이션의 경우 이전에 설명한 옵션(JSON, Polyfill) 중 하나가 작동할 수 있습니다. 하지만 특히 이러한 기기 중 다수는 여러 가지 이유로 업데이트가 어렵거나 불가능합니다. 이 경우 확장 프로그램이 가장 좋은 옵션일 수 있습니다. 클라이언트 브라우저가 기기를 수정하지 않고도 정확히 동일한 방식으로 데이터를 계속 읽을 수 있기 때문입니다.

웹사이트의 지연 템플릿

웹 개발자는 클라이언트 측에서 XSLT를 사용하여 시맨틱 마크업에 프레젠테이션 마크업을 적용하는 경우가 있습니다. 이는 JavaScript 생태계와 별개인 지연 템플릿 언어로 작동합니다.

이러한 일반적인 문제에는 두 가지 해결 방법이 있습니다. 이러한 방식으로 빌드된 기존 사이트의 경우 가장 쉬운 해결 방법은 기존 기능을 유지하기 위해 폴리필을 추가하는 것입니다. 또는 서버 측에서 XSLT 변환을 수행하고 원시 XML이 아닌 결과 HTML을 클라이언트에 제공합니다. 이러한 속성에 대한 장기적인 해결책은 최신 JavaScript 또는 JSON 기반 프레임워크로 이전하는 것입니다.

이 XSLT 지원 중단과 관련하여 Chrome에서 특정 문제가 발생하면 여기에서 버그를 신고하세요.

XSLT 사용 감지 방법

일반적으로 XSLT와 같은 지원 중단된 기능은 몇 가지 방법으로 코드베이스에서 감지할 수 있습니다. 이 섹션에서는 그중 두 가지를 설명합니다.

Reporting API

Reporting API는 웹 애플리케이션이 기능 지원 중단을 비롯한 다양한 플랫폼 기능 및 조건에 관한 보고서를 사용하는 일반적인 보고 메커니즘입니다. XSLT 지원 중단을 보고하도록 설정하려면 다음과 같은 코드 스니펫을 사용할 수 있습니다.

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();

CodePen에서 이 코드의 작동 모습 보기

엔터프라이즈 기존 기술 보고서

기업 관리자의 경우 기존 기술 보고서를 사용하여 지원 중단된 기능 사용을 자동으로 수집하고 사용자 친화적인 방식으로 다시 보고할 수 있습니다. 이 기능을 사용 설정하는 방법에 대한 자세한 내용은 이 Google 지원 도움말을 참조하세요.