접속 분석, 광고, 채팅, 결제 화면 부품, CDN에서 불러오는 라이브러리. 많은 사이트가 직접 작성하지 않은 스크립트를 페이지를 표시할 때마다 불러오며, 그 스크립트는 사이트 자체 코드와 같은 권한으로 실행됩니다. 이 글은 외부 스크립트를 파악하고, 할 수 있는 일을 좁히고, 변화를 알아차리는 절차를 OWASP와 MDN의 1차 자료를 바탕으로 설명합니다(공격 방법은 다루지 않습니다).
서드파티 스크립트가 위험한 이유
OWASP의 「Third Party JavaScript Management Cheat Sheet」는 서드파티 JavaScript를 넣을 때의 위험을 세 가지로 나눕니다.
- 변경에 대한 통제 상실
- 제공자의 코드가 개발·테스트할 때와 같게 유지된다는 보장은 보통 없습니다. 제공자는 언제든 새 기능을 넣을 수 있습니다
- 사용자 기기에서 임의 코드 실행
- 서드파티 코드는 넣기 전에 검토되는 일이 드물고, 사용자와 같은 권한으로 실행됩니다. OWASP는 제공자 도메인이 만료되어 다른 사람이 다시 등록한 뒤 악성 코드를 올리는 사례도 듭니다
- 서드파티로의 정보 노출
- 스크립트를 불러오면 브라우저가 제공자 서버에 직접 접속하므로, IP 주소와 제공자가 이전에 설정한 쿠키 등도 제공자에게 전달됩니다
태그 관리자를 쓰면 사정이 더 복잡해집니다. OWASP는 태그 관리자가 돌려주는 내용은 관리 화면에서 바로 바꿀 수 있고, 다음 페이지 표시부터 바뀐 코드가 실행된다고 설명합니다. 따라서 사이트의 소스 코드만 봐서는 실제로 실행되는 코드 전체를 알 수 없습니다.
이 사이트도 이런 유형의 사례를 다뤘습니다: Polymarket 서드파티 스크립트 사건. 사용자가 보고 있는 페이지에서 실행되는 코드가 문제가 된 경우입니다.
내 사이트의 페이지(표시 내용·폼 입력·쿠키)
↓ 같은 페이지 안에서 실행
내 스크립트
직접 검토하고 배포할 수 있다
서드파티 스크립트
제공자가 내용을 바꿀 수 있다. 페이지를 읽을 수 있다
외부로 전송하는 폼
입력이 다른 출처로 간다
↓ 좁히는 수단
목록 정리와 제거
SRI / 직접 배포 / CSP script-src·connect-src
CSP form-action
방어 방법: 6단계
실행 중인 서드파티 스크립트를 모두 적는다
먼저 목록을 만듭니다. HTML에 직접 적힌 것, 태그 관리자에 등록한 것, 라이브러리나 플러그인이 스스로 불러오는 것을 포함합니다.
하나씩 어느 출처에서 불러오는지, 누구의 서비스인지, 왜 넣었는지, 어떤 페이지에서 실행되는지, 문제가 생기면 누가 어떻게 끄는지를 적습니다. iframe이나 이미지처럼 외부 서버에 접속하는 것도 함께 적어 두면 나중에 CSP 설정에 그대로 쓸 수 있습니다.
쓰지 않는 것을 빼고, 중요한 페이지에서는 더 줄인다
목록에서 '목적을 모름', '담당자 없음'인 항목은 제거 후보입니다. 지난 캠페인용 태그나 이미 바꾼 분석 서비스가 남아 있는 경우가 흔합니다.
로그인, 결제, 비밀번호나 이메일 변경, 관리 화면처럼 입력의 가치가 높은 페이지에서는 꼭 필요한 것만 남깁니다. 모든 페이지 공통 템플릿에 넣은 태그는 이런 페이지에도 들어갑니다. 페이지 종류별로 불러올지 정하세요. 페이지 내용에 접근할 필요가 없는 부품은 OWASP가 설명하듯 다른 도메인의 iframe(sandbox 속성 포함)에 넣어 페이지와 분리하는 방법도 있습니다.
태그 관리자의 게시 권한을 좁힌다
OWASP는 데이터 레이어(태그에 넘기는 값을 모은 객체)가 격리 장치가 아니며, 태그 관리자 컨테이너는 사용자 정의 JavaScript와 HTML 태그를 실행할 수 있다고 주의합니다. 그리고 게시 권한을 제한하고 변경을 애플리케이션 코드처럼 검토하라고 권합니다.
구체적으로는 네 가지부터 시작합니다. 게시할 수 있는 사람을 몇 명으로 제한하고, 관리 화면 계정에 2단계 인증을 켜고, 필요 없으면 사용자 정의 HTML 태그를 끄고, 게시 전에 다른 사람이 확인합니다.
내용이 고정된 파일에는 SRI를 붙이거나 직접 배포한다
SRI(하위 리소스 무결성)는 <script> 등의 integrity 속성에 파일 해시를 적어 두고, 받은 파일이 일치하지 않으면 브라우저가 불러오기를 거부하는 방식입니다. MDN에 따르면 쓸 수 있는 해시는 sha256·sha384·sha512이고, 다른 출처에서 불러올 때는 제공자가 CORS를 허용해야 하며 crossorigin 속성도 붙입니다.
SRI는 버전이 붙은 라이브러리처럼 내용이 바뀌지 않는 파일에만 쓸 수 있습니다. 제공자가 수시로 업데이트하는 분석 태그에 붙이면 업데이트할 때마다 불러올 수 없게 됩니다. 이 경우 검토한 버전을 내 사이트에서 배포하거나(OWASP가 말하는 in-house mirroring), 중요한 페이지에서는 불러오지 않는 쪽을 택합니다. 라이브러리의 알려진 취약점은 의존성 취약점 스캐너에 lockfile을 붙여 확인할 수 있습니다.
CSP로 불러오는 곳과 보내는 곳을 좁힌다
CSP(Content-Security-Policy)에는 1단계 목록을 바탕으로 허용할 출처를 적습니다. script-src는 스크립트를 불러오는 곳을, connect-src는 fetch·XMLHttpRequest·WebSocket·EventSource·sendBeacon 등의 접속 대상을 제한합니다(MDN).
폼 전송 대상을 제한하는 form-action은 default-src로 대체되지 않습니다. MDN은 설정하지 않으면 무엇이든 허용된다고 설명합니다. 폼을 내 사이트로만 보낸다면 form-action 'self'를 명시하세요.
바로 적용하면 정상 기능이 멈출 수 있으므로, 먼저 Content-Security-Policy-Report-Only로 위반 보고만 모읍니다. MDN에 따르면 보고를 받으려면 report-to를 지정해야 하고, 이 헤더는 <meta> 요소에서 쓸 수 없습니다(폐지 예정인 report-uri로도 보고를 보낼 수 있습니다). CSP 빌더로 조합을 시험해 볼 수 있습니다. 헤더 전체의 사고방식은 보안 헤더 고르는 법에 정리했습니다.
변화를 알아차릴 수 있게 하고, 끄는 절차를 정해 둔다
서드파티 스크립트는 내가 아무것도 하지 않아도 바뀝니다. 매달 한 번 등 정해진 간격으로 목록과 실제 상태를 비교하고, CSP 위반 보고에 모르는 대상이 나오면 조사합니다. 제공자의 보안 공지를 받을 수 있게 해 둡니다.
문제가 생겼을 때 어떤 태그를, 누가, 어느 화면에서 끄는지 문서로 남깁니다. 카드 결제 페이지를 운영한다면 PCI DSS v4.0.1의 결제 페이지 보안 요구사항 6.4.3과 11.6.1이 2025년 3월 31일부터 유효하다는 점도 확인하세요(PCI SSC). 카드 데이터 처리를 모두 준수 사업자에게 맡긴 가맹점용 SAQ A에서는 이 두 요구사항이 빠지고, 대신 자사 사이트가 전자상거래 시스템에 영향을 줄 수 있는 스크립트 공격에 취약하지 않음을 확인하는 자격 조건이 추가되었습니다(표준 자체의 요구사항은 그대로입니다).
네 가지 대책이 막는 것과 막지 못하는 것
| 대책 | 막는 것 | 막지 못하는 것 | 적합한 대상 |
|---|---|---|---|
| 제거 | 그 스크립트와 관련된 모든 위험 | ― | 목적을 모르거나 쓰지 않는 스크립트 |
| SRI | 전송 중 또는 제공자 쪽에서의 파일 교체 | 변조되지 않은 스크립트가 정상 기능으로 보내는 정보. 제공자가 업데이트하면 불러올 수 없음 | 버전이 붙은 고정 파일 |
| 직접 배포 | 제공자 쪽에서의 교체 | 직접 업데이트하지 않으면 오래된 버전이 남음 | 검토 후 계속 쓰는 라이브러리 |
| CSP | 허용하지 않은 출처에서의 로드, 허용하지 않은 대상으로의 통신·폼 전송 | 허용한 출처 자체가 침해된 경우. 허용한 대상으로 보내지는 정보 | 모든 페이지(단계적으로 도입) |
퍼지기 쉬운 상태
- 모든 페이지 공통 템플릿에 태그를 넣었다
- 태그 관리자 게시 권한을 많은 사람이 가지고 있다
- CSP가 없거나
form-action을 적지 않았다 - 서드파티 스크립트 목록이 없고 끄는 방법도 정해지지 않았다
좁혀진 상태
- 페이지 종류별로 불러오는 태그를 나눈다
- 게시할 수 있는 사람이 적고, 변경은 다른 사람이 확인한다
- CSP로 출처·접속 대상·폼 전송 대상을 고정했다
- 목록이 있고 정기적으로 실제 상태와 비교한다
사이트 투명성 체커로 결과 확인하기
목록을 만들었다면 실제 상태와 비교합니다. 내가 관리하는 사이트의 홈페이지 URL을 사이트 투명성 체커에 넣으면, 가져온 HTML에서 다음 항목을 찾아냅니다.
- 외부 스크립트/리소스의 출처
- script·iframe·img·link(stylesheet·preload 등)가 참조하는 다른 출처. 1단계 목록에 없는 것은 무엇인지 조사한다
- 분석·광고 태그(추적)
- 자주 쓰이는 분석·광고·모니터링 서비스를 이름으로 표시. 이름은 참조 대상의 분류일 뿐 안전 판정이 아니다
- 알 수 없는 제3자 스크립트(입력을 읽을 가능성)
- 다른 출처에서 불러오는 스크립트. 제공자가 유명하다고 안전하다고 판정하지 않는다
- 외부로 전송하는 폼
- form의 action이나 button의 formaction이 다른 출처를 가리키는 것. 의도한 것이 아니면 가장 먼저 확인하고 CSP form-action으로 고정한다
- 쿠키 설정
- 가져온 응답에 Set-Cookie가 있는지. JavaScript로 설정하는 쿠키는 확인하지 않는다
이 도구에는 한계가 있습니다. 홈페이지(언어별 홈페이지와 index.html 포함)만 가져오고, 스크립트를 실행하지 않으며, 포함된 파일을 추가로 가져오지 않습니다. 태그 관리자가 나중에 불러오는 스크립트나 버튼을 눌렀을 때만 일어나는 요청은 보이지 않습니다. 그래서 다음 확인도 함께 합니다.
- 확인할 페이지(로그인·결제 페이지 포함)를 열고 브라우저 개발자 도구를 연다
- Network 탭에서 기록하면서 가짜 데이터로 실제로 입력·조작한다
- 목록에 없는 외부 도메인으로의 요청이 없는지 본다
- CSP를 설정한 뒤에는 보안 헤더 진단으로 헤더가 실제로 반환되는지 확인한다
일본에서 사이트를 운영하는 경우: 외부 전송 규율
일본 총무성에 따르면 2022년 6월 전기통신사업법 개정으로, 태그나 정보 수집 모듈로 이용자 정보를 외부에 보내게 할 때 이용자가 확인할 수 있게 하는 규율이 생겼습니다(2023년 6월 16일 시행). 대상은 전기통신사업을 영위하는 자이며, 총무성은 메시지 매개 서비스, SNS, 검색 서비스, 뉴스 사이트·정리 사이트 등 정보 제공 서비스를 주요 대상으로 들면서, 자사 상품의 온라인 판매·기업 홈페이지·개인 블로그는 전기통신사업에 해당하지 않아 대상이 아니라고 설명합니다.
대상이라면 보내는 정보의 내용, 그 정보를 취급하는 자의 성명 또는 명칭, 이용 목적을 이용자에게 통지하거나 쉽게 알 수 있는 상태에 두는 등의 대응이 필요합니다. 1단계 목록은 이 공표 내용을 만들 때도 쓸 수 있습니다. 대상인지는 총무성의 설명과 흐름도로 확인하세요.
이 사이트의 관점: 지명도가 아니라 그 페이지에서 무엇을 읽을 수 있는지로 판단한다
서드파티 스크립트를 점검하다 보면 '유명한 서비스니까 괜찮다'는 판단으로 끝나기 쉽습니다. 하지만 OWASP가 가장 큰 위험으로 꼽는 것은 제공자의 서버가 침해되는 일입니다. 유명한 서비스일수록 많은 사이트에 들어가 있어, 침해되면 영향도 넓게 퍼집니다.
그래서 이 사이트의 사이트 투명성 체커는 제공자가 유명해도 안전하다고 표시하지 않습니다. 판단 기준은 세 가지입니다. 그 스크립트가 어떤 페이지에서 실행되는지, 거기서 무엇을 읽을 수 있는지, 문제가 생기면 몇 분 안에 끌 수 있는지입니다.
출처(1차 자료)
- OWASP 「Third Party JavaScript Management Cheat Sheet」 — cheatsheetseries.owasp.org(세 가지 위험, 태그 관리자, SRI, iframe 분리, in-house mirroring)
- MDN 「Subresource Integrity」 — developer.mozilla.org(integrity 속성, 쓸 수 있는 해시, CORS와 crossorigin 속성)
- MDN 「Content Security Policy (CSP)」 — developer.mozilla.org(script-src, report-only 시험)
- MDN 「CSP: form-action」 — developer.mozilla.org(default-src 대체 없음)
- MDN 「CSP: connect-src」 — developer.mozilla.org(대상 API)
- MDN 「Content-Security-Policy-Report-Only」 — developer.mozilla.org(report-to 필요, meta 요소에서는 사용 불가)
- PCI SSC 「Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A」(2025년 1월 30일) — blog.pcisecuritystandards.org(요구사항 6.4.3·11.6.1은 2025년 3월 31일부터 유효)
- 일본 총무성 「外部送信規律」(일본어) — soumu.go.jp(취지, 대상, 공표 사항)
다음으로 읽기
- 도구: 사이트 투명성 체커 / CSP 빌더 / 보안 헤더 진단
- 설정: 보안 헤더 고르는 법
- 사건: Polymarket 서드파티 스크립트 사건
- 용어: XSS란 / PCI DSS란