• 목록

웹사이트에서 보안 사고가 발생했다고 하면 일반적으로 서버 침입이나 데이터베이스 유출을 먼저 떠올린다. 하지만 서버가 정상적으로 동작하고 상품 페이지와 결제 화면까지 문제없이 열리는 상황에서도 사용자의 브라우저에서는 사이트 운영자가 의도하지 않은 JavaScript가 실행될 수 있다.

Cloudflare는 2026년 9월 16일 실제 온라인 상점에서 발견한 이러한 사례를 공개했다. Cloudflare의 클라이언트 사이드 보안(Client-Side Security) 시스템이 실제 트래픽에서 탐지한 것은 서로 다른 4개의 악성 JavaScript 캠페인이었으며, 여기에 포함된 악성 페이로드(Payload)는 총 8개였다.

이번 사례는 서버에서 발생하는 보안 문제와 사용자의 브라우저에서 발생하는 보안 문제가 서로 다른 관찰 영역이라는 점을 보여준다.

정상적으로 보이는 웹사이트에서 발견된 악성 JavaScript

Cloudflare가 공개한 사례에서 웹사이트 자체가 작동하지 않은 것은 아니었다.

페이지가 열리고 상품이 표시됐으며 결제 기능도 계속 작동했다. 그러나 그 아래에서 실행되는 일부 JavaScript는 사이트 운영자가 의도하지 않은 동작을 수행하고 있었다.

Cloudflare가 분류한 네 가지 캠페인의 동작은 서로 달랐다.

첫 번째 사례에서는 특정 사용자가 상품을 클릭했을 때 제휴 마케팅 경로를 조작해 공격자가 제휴 수수료를 가져갈 수 있도록 했다.

두 번째 사례에서는 사용자의 클릭 없이도 화면 밖의 보이지 않는 iframe 등을 이용해 제휴 요청을 발생시키는 방식이 사용됐다.

세 번째 사례에서는 사용자를 추적하는 기능과 함께 외부 서버에서 추가 JavaScript를 불러와 실행할 수 있는 구조가 발견됐다.

네 번째 사례에서는 특정 모바일 방문자를 대상으로 일부 광고·분석·지원 관련 기능을 방해하고 별도의 추적 요청을 전송하는 동작이 확인됐다.

즉, 네 사례가 하나의 동일한 공격 방식을 사용한 것은 아니다. 공통점은 문제가 되는 JavaScript가 최종적으로 사용자의 브라우저에서 실행됐다는 것이다.

모든 방문자에게 같은 행동을 한 것도 아니었다

이번 사례에서 주목할 부분은 일부 악성 JavaScript가 페이지에 접속했다고 항상 동일한 행동을 하지 않았다는 점이다.

Cloudflare 분석에 따르면 일부 코드는 방문자의 기기, 국가, 접속 시간, 유입 경로(Referrer), 브라우저 상태 등을 확인했다. 다른 사례에서는 UTM 태그, 화면 크기, IP 관련 정보, 로컬 스토리지(localStorage)와 같은 조건도 이용됐다.

조건이 맞지 않으면 코드가 악성 행동을 수행하지 않을 수 있었다.

예를 들어 첫 번째 캠페인의 일부 활성 스크립트는 특정 조건을 충족한 사용자의 클릭이 발생한 뒤 로컬 스토리지에 3일간의 대기 상태를 기록했다. 이후 같은 기기에서는 일정 기간 다시 동작하지 않는 방식이 사용됐다.

또 페이지가 처음 열릴 때 존재하지 않고 나중에 동적으로 생성되는 상품 요소를 감시하기 위해 JavaScript API인 MutationObserver를 사용한 사례도 있었다.

이 때문에 HTML을 한 번 불러와 검사하는 방식과 실제 사용자의 브라우저에서 시간이 지나면서 발생하는 JavaScript 동작을 관찰하는 것은 서로 다른 결과를 만들 수 있다.

공개 스캐닝 서비스에서도 악성 판정이 없었던 사례

Cloudflare는 탐지된 8개 페이로드를 이후 다른 보안 스캐닝 서비스에서도 확인했다.

Cloudflare가 사후 검토한 시점 기준으로 8개 가운데 7개는 VirusTotal에 존재하지 않았으며, URLScan에서는 8개 모두 악성으로 판정되지 않았다고 밝혔다.

한 사례에서는 관련 파일이 URLScan에 약 2년 반 동안 색인되어 있었지만 분류 상태가 'No classification'으로 남아 있었다고 Cloudflare는 설명했다.

다만 이 결과가 모든 보안 스캐너의 탐지 성능을 의미하는 것은 아니다. 이는 Cloudflare가 이번에 공개한 8개 페이로드를 대상으로 확인한 결과다.

따라서 이를 근거로 일반적인 보안 스캐닝 서비스가 클라이언트 사이드 공격을 탐지하지 못한다고 확대 해석할 수는 없다.

이번 사례에서 확인할 수 있는 것은 정적 파일이나 URL이 알려져 있는지 확인하는 것과 실제 브라우저에서 코드가 어떤 조건으로 어떤 행동을 수행하는지 분석하는 것은 서로 다른 보안 관찰 방식이라는 점이다.

Cloudflare는 JavaScript의 동작 구조를 분석했다

Cloudflare는 이번 악성 JavaScript 탐지에 그래프 신경망(Graph Neural Network, GNN)을 사용했다고 밝혔다.

JavaScript를 하나의 텍스트 덩어리로만 검사하는 것이 아니라 코드의 구조를 그래프로 표현해 함수와 코드 요소가 어떻게 연결되고 어떤 코드가 다른 코드를 호출하는지 등을 분석하는 방식이다.

Cloudflare 설명에 따르면 이 방식은 URL이나 파일의 바이트 패턴만을 기준으로 판단하는 대신 코드 구조를 분석하기 때문에 코드 축소(Minification), 이름 변경, 일부 난독화가 적용된 경우에도 의심스러운 패턴을 분석할 수 있다.

GNN이 악성으로 판단하는 스크립트는 Cloudflare가 분석하는 전체 트래픽의 0.3% 미만이라고 회사는 밝혔다.

이렇게 선별된 스크립트는 다시 Workers AI에서 실행되는 경량 대규모 언어 모델(LLM)의 분석을 거친다. Cloudflare는 이 두 번째 분석을 통해 거짓 양성(False Positive)을 줄이는 구조를 사용하고 있다고 설명했다.

복잡한 스크립트에 대해서는 여러 AI 모델을 각각 독립적으로 실행해 분석 결과를 비교하는 방식도 사용하고 있다.

이는 Cloudflare가 공개한 자체 탐지 시스템의 구조이며, 이번 발표만으로 다른 보안 탐지 방식과의 전반적인 성능 우위를 의미하지는 않는다.

서버 측 보안과 클라이언트 측 보안은 관찰 지점이 다르다

웹사이트를 방문하면 서버는 브라우저에 HTML, CSS, JavaScript 등의 리소스를 전달한다.

이후 JavaScript는 사용자의 브라우저에서 실행된다.

현대 웹사이트에서는 자체 제작한 코드뿐 아니라 분석 도구, 광고 시스템, 결제 기능, 고객 상담 도구, 태그 관리 시스템 등 다양한 스크립트가 함께 실행될 수 있다.

이처럼 사용자의 브라우저에서 실행되는 코드와 그 동작을 대상으로 하는 영역을 클라이언트 사이드 보안(Client-Side Security)이라고 부른다.

이는 서버 측 보안(Server-Side Security)과 관찰 대상이 다르다.

서버 측에서는 서버 애플리케이션, 데이터베이스, API, 인증 시스템 등의 보안이 주요 대상이라면 클라이언트 측에서는 브라우저가 어떤 JavaScript를 실행하고 어떤 외부 자원과 통신하는지가 중요한 관찰 대상이 된다.

이번 Cloudflare 사례에서도 최초 침입 경로가 모두 밝혀진 것은 아니다.

일부 악성 코드는 온라인 상점의 HTML에 직접 삽입돼 있었지만 Cloudflare는 관리 계정 탈취, 무단 템플릿 변경, 감염된 테마나 플러그인 등을 가능한 경로로 제시했을 뿐 실제 최초 침입 경로를 특정하지 않았다.

따라서 이번 사례 전체를 단순히 '외부 JavaScript가 해킹된 사건'이나 '제3자 스크립트 공격'이라고 정의하는 것은 정확하지 않다.

더 넓은 공통점은 브라우저에서 실행되는 JavaScript를 통해 악성 동작이 이루어졌다는 것이다.

결제 보안 표준에서도 브라우저의 스크립트를 별도로 다룬다

브라우저에서 실행되는 코드의 보안은 특정 보안 기업만 사용하는 개념은 아니다.

PCI Security Standards Council의 PCI DSS Requirement 6.4.3 역시 소비자의 브라우저에서 결제 페이지가 렌더링될 때 승인되지 않은 코드가 실행되는 것을 방지하는 것을 목적으로 한다.

결제 페이지에서 실행되는 스크립트의 승인 여부와 무결성 등을 별도로 관리 대상으로 다루는 것이다.

웹 보안 표준에서도 브라우저가 가져오거나 실행할 수 있는 리소스를 통제하는 기술이 존재한다.

W3C가 개발 중인 콘텐츠 보안 정책(Content Security Policy, CSP) Level 3는 특정 웹페이지가 어떤 리소스를 가져오거나 실행할 수 있는지를 웹 개발자가 제어할 수 있도록 하는 메커니즘을 정의한다.

다만 CSP 역시 콘텐츠 삽입 취약점 자체를 제거하는 기술은 아니다. W3C는 이를 입력 검증이나 출력 인코딩을 대체하는 것이 아니라 추가적인 방어 계층(Defense in Depth)으로 설명한다.

이번 사례가 보여준 클라이언트 사이드 공격의 특징

Cloudflare가 공개한 네 캠페인은 서로 다른 방식으로 동작했다.

제휴 수수료를 가로채는 코드가 있었고, 사용자의 검색이나 클릭을 방해하는 코드도 있었으며, 외부 서버에서 추가 JavaScript를 가져와 실행하거나 분석·모니터링 도구의 동작을 방해하는 사례도 있었다.

일부 코드는 특정 방문 조건에서만 활성화됐다.

때문에 웹페이지가 정상적으로 표시되고 서버가 정상적으로 응답한다는 사실만으로 브라우저에서 실행되는 모든 코드의 정상 여부까지 확인되는 것은 아니다.

서버가 어떤 응답을 보내는지와 최종 사용자의 브라우저에서 어떤 코드가 실제로 실행되는지는 웹 보안에서 서로 다른 관찰 지점이다.

이번 Cloudflare 사례는 바로 그 두 번째 영역에서 발견된 실제 사례다.

용어 정리

클라이언트 사이드 보안(Client-Side Security)
사용자의 브라우저에서 실행되는 코드와 리소스, 외부 통신 등을 대상으로 하는 보안 영역이다.

JavaScript
웹페이지에 동적인 기능과 사용자 상호작용 등을 구현하기 위해 널리 사용되는 프로그래밍 언어다. 브라우저에서 실행되는 대표적인 클라이언트 사이드 코드다.

악성 페이로드(Malicious Payload)
공격 목적의 실제 동작을 수행하는 코드 또는 데이터 부분을 의미한다.

제3자 스크립트(Third-party Script)
웹사이트 자체가 아닌 외부 서비스나 도메인에서 제공되는 JavaScript다. 분석, 광고, 결제, 상담 등 다양한 기능에서 사용된다.

그래프 신경망(Graph Neural Network, GNN)
그래프 형태로 표현된 데이터의 관계와 구조를 학습하는 머신러닝 모델이다. Cloudflare는 이번 시스템에서 JavaScript 코드 구조 분석에 이를 사용했다고 밝혔다.

거짓 양성(False Positive)
정상적인 대상을 보안 시스템이 악성 또는 위험한 것으로 잘못 판단하는 경우를 의미한다.

콘텐츠 보안 정책(Content Security Policy, CSP)
웹페이지가 어떤 리소스를 가져오거나 실행할 수 있는지 등을 브라우저에 선언하는 웹 보안 메커니즘이다.

MutationObserver
웹페이지의 DOM 구조가 변경되는 것을 감지할 수 있는 JavaScript API다.

로컬 스토리지(localStorage)
브라우저가 웹사이트별 데이터를 사용자의 기기에 저장할 수 있도록 제공하는 웹 저장소 기능이다.

출처

Cloudflare — 「When scanners miss the attack: how Cloudflare Client-Side Security protects storefronts」
2026년 9월 16일 공개. 이번 글에서 다룬 4개 악성 JavaScript 캠페인과 8개 페이로드, 탐지 방식 및 분석 결과의 직접적인 1차 자료.
https://blog.cloudflare.com/client-side-security-finds-4-malicious-campaigns/

PCI Security Standards Council — 「How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?」
PCI DSS Requirement 6.4.3의 목적과 소비자의 브라우저에서 실행되는 결제 페이지 코드 관리에 관한 공식 설명.
https://www.pcisecuritystandards.org/faqs/how-does-pci-dss-requirement-6-4-3-apply-to-3ds-scripts-called-from-a-merchant-check-out-page-as-part-of-3ds-processing/

W3C Web Application Security Working Group — 「Content Security Policy Level 3」
2026년 8월 13일 Working Draft. 웹페이지가 가져오거나 실행할 수 있는 리소스를 통제하는 CSP의 기술 규격과 한계를 설명하는 공식 문서.
https://www.w3.org/TR/CSP/