이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

Mason Freed

Dominik Röttsches

게시일: 2025년 10월 29일

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

Chromium에서 XSLTProcessor JavaScript API와 XML 스타일시트 처리 명령을 비롯한 XSLT를 공식적으로 지원 중단했습니다. 버전 155 (2026년 11월 17일)부터 지원이 삭제될 예정입니다. Firefox 및 WebKit 프로젝트에서도 브라우저 엔진에서 XSLT를 삭제할 계획을 밝혔습니다. 이 문서에서는 XSLT를 삭제하여 Chrome을 더 안전하게 만드는 방법을 설명하고, 이러한 기능이 브라우저에서 삭제되기 전에 이전할 수 있는 경로를 제공합니다.

무엇이 삭제되나요?

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

XSLTProcessor 클래스 (예: new XSLTProcessor())
XSLT 처리 명령(예: <?xml-stylesheet … ?>)

Chrome 타임라인

Chrome에는 다음과 같은 요금제가 있습니다.

Chrome 142 (2025년 10월 28일): Chrome에 조기 경고 콘솔 메시지가 추가되었습니다.
Chrome 143 (2025년 12월 2일): API 공식 지원 중단 - 지원 중단 경고 메시지가 콘솔과 Lighthouse에 표시되기 시작합니다.
Chrome 148 (2026년 3월 10일 Canary): Canary, 개발자, 베타 버전에서 조기 경고로 기본적으로 XSLT를 사용 중지하기 시작합니다.
Chrome 152 (2026년 8월 25일): 오리진 트라이얼 (OT) 및 엔터프라이즈 정책 (EP)이 테스트를 위해 출시됩니다. 이를 통해 사이트와 기업은 삭제일이 지난 후에도 기능을 계속 사용할 수 있습니다.
Chrome 155 (2026년 11월 17일): 오리진 트라이얼 및 엔터프라이즈 정책 참여자를 제외한 모든 사용자의 안정화 버전에서 XSLT가 작동하지 않습니다.**
Chrome 164 (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" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

다음 XSL 스타일시트

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

브라우저에 표시할 수 있도록 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만 기본적으로 지원합니다. 이러한 발전의 부족과 JSON의 와이어 형식 사용 증가, 더 유연하고 강력한 DOM 조작 및 템플릿을 제공하는 JavaScript 라이브러리 및 프레임워크 (예: jQuery, React, Vue.js)의 등장으로 인해 클라이언트 측 XSLT 사용이 크게 감소했습니다. 웹브라우저 내에서의 역할은 이러한 JavaScript 기반 기술로 대체되었습니다.

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

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

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

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

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

XML 파싱 보안 개선

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

마이그레이션 방법

마이그레이션을 위한 몇 가지 대체 경로가 있습니다.

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 기능을 사용하지 않으면서 계속 작동하도록 지원하는 polyfill이 있습니다. 폴리필은 GitHub에 있습니다.

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

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

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

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

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

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

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

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

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

확장 프로그램

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

특히 XSLT가 사용 중지된 경우 Chrome은 이제 사용자가 확장 프로그램을 찾을 수 있도록 확장 프로그램 검색 페이지로 직접 연결되는 경고 배너를 표시합니다.

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

구체적인 사용 사례

HTML 표준에 관한 토론에서 몇 가지 구체적인 사용 사례가 확인되었습니다. 이 섹션에서는 오늘날 XSLT를 사용하는 XML 리소스를 게시하는 개발자를 위해 앞으로 나아갈 길을 추천하기 위해 각 리소스에 대해 구체적으로 설명합니다.

RSS 및 Atom 피드

기존 RSS 또는 Atom 피드에서는 브라우저에서 직접 볼 때 원시 XML 피드를 사람이 읽을 수 있도록 XSLT가 사용됩니다. 기본 사용 사례는 사용자가 사이트의 RSS 피드 링크를 실수로 클릭할 때 RSS 리더에 해당 링크를 붙여넣는 대신 읽을 수 있는 형식화된 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](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 기반 프레임워크로 이전하는 것입니다.