콤퓨타지식 클라이언트 사이드 보안(Client-Side Security)이란? 브라우저에서 실행되는 JavaScript를 보호하는 원리
페이지 정보
본문
작성일
웹사이트의 보안을 생각하면 서버, 데이터베이스, 관리자 계정, API 등을 먼저 떠올리기 쉽다. 그러나 웹서비스의 일부 코드는 서버가 아니라 방문자의 브라우저에서 실행된다.
대표적인 것이 JavaScript다.
사용자가 웹페이지에 접속하면 서버가 HTML, CSS, JavaScript 등의 리소스를 전달하고, 브라우저는 이를 해석해 화면과 기능을 구성한다. 이 과정에서 웹사이트가 직접 작성한 코드뿐 아니라 분석 도구, 광고, 결제, 채팅, 지도, 태그 관리 시스템과 같은 외부 서비스의 JavaScript도 함께 실행될 수 있다.
따라서 웹사이트의 보안은 서버에서 무엇이 일어나는지만으로 설명되지 않는다.
사용자의 브라우저에서 어떤 코드가 로드되고, 어떤 코드가 실행되며, 어떤 데이터에 접근하고, 어떤 외부 시스템과 통신하는지 역시 하나의 독립적인 보안 영역이 된다.
이를 클라이언트 사이드 보안(Client-Side Security)이라고 한다.
서버 사이드와 클라이언트 사이드는 무엇이 다른가
웹서비스는 크게 서버 측과 클라이언트 측으로 나누어 생각할 수 있다.
서버 사이드(Server-Side)는 웹서버와 애플리케이션 서버에서 실행되는 영역이다. 데이터베이스 조회, 회원 인증, 권한 확인, 결제 처리, API 호출과 같은 작업이 대표적이다.
반면 클라이언트 사이드(Client-Side)는 사용자의 웹브라우저에서 실행되는 영역이다.
HTML이 문서 구조를 만들고 CSS가 화면 표현을 담당한다면 JavaScript는 사용자 입력 처리, 화면 변경, 데이터 요청, 외부 서비스 연결 등 다양한 동적 기능을 담당한다.
이를 단순화하면 다음과 같다.
Server
↓ HTML · CSS · JavaScript 전달
Browser
↓ JavaScript 실행
DOM 변경 · 사용자 입력 처리 · API 호출 · 외부 서비스 통신
따라서 서버가 정상이라고 해서 브라우저에서 실행되는 모든 코드까지 자동으로 정상이라고 볼 수는 없다.
서버 보안과 클라이언트 사이드 보안은 서로 연결되어 있지만 관찰하는 지점이 다르다.
현대 웹사이트에서는 하나의 페이지에서 여러 JavaScript가 실행된다
웹페이지의 JavaScript가 모두 해당 사이트 개발자가 직접 만든 것은 아니다.
현대 웹사이트에서는 외부 서비스를 연결하기 위해 제3자 스크립트(Third-party Script)를 사용하는 경우가 많다.
예를 들면 웹 분석, 광고와 전환 측정, 고객 상담, 결제, 지도, 소셜 기능, A/B 테스트, 태그 관리 등의 기능이다.
웹사이트가 외부 JavaScript를 불러오면 해당 코드는 방문자의 브라우저에서 웹사이트의 일부로 실행될 수 있다.
이 때문에 외부 스크립트를 사용하는 것은 단순히 다른 서버에서 파일 하나를 가져오는 것 이상의 의미를 갖는다.
W3C는 하위 리소스 무결성(Subresource Integrity, SRI)을 설명하면서 웹 애플리케이션이 제3자의 리소스를 포함하면 그 리소스에 일정 부분 신뢰를 위임하게 된다고 설명한다.
즉 웹사이트가 직접 작성한 코드가 안전하더라도 웹페이지가 의존하는 외부 리소스가 변경되거나 침해되면 최종 사용자의 브라우저에서 실행되는 코드 역시 영향을 받을 수 있다.
클라이언트 사이드 보안에서는 무엇을 보호하는가
클라이언트 사이드 보안의 대상은 단순히 JavaScript 파일 하나가 아니다.
크게 보면 네 가지 질문으로 나눌 수 있다.
첫 번째는 어떤 코드가 실행되고 있는가이다.
웹페이지에 포함된 자체 스크립트와 외부 스크립트를 파악해야 한다.
두 번째는 그 코드가 원래 허용된 코드인가이다.
웹사이트 운영자가 승인한 스크립트인지, 예상하지 못한 코드가 추가됐는지를 구분하는 문제다.
세 번째는 코드가 변경되지 않았는가이다.
원래 승인된 외부 JavaScript라 하더라도 이후 파일의 내용이 바뀔 수 있다.
네 번째는 실행된 코드가 실제로 무엇을 하고 있는가이다.
어떤 DOM 요소를 읽거나 변경하는지, 어떤 사용자 데이터를 다루는지, 어떤 외부 서버와 통신하는지 등이 포함된다.
따라서 클라이언트 사이드 보안은 단순한 파일 검사를 넘어
Script → Integrity → Execution → Behavior → Connection
의 관계를 관찰하는 영역으로 볼 수 있다.
DOM은 왜 중요한가
DOM(Document Object Model)은 브라우저가 HTML 문서를 프로그램이 다룰 수 있는 객체 구조로 표현한 것이다.
JavaScript는 DOM을 이용해 웹페이지의 내용을 읽거나 변경할 수 있다.
버튼을 누르면 메뉴가 열리고, 상품을 장바구니에 추가하면 숫자가 바뀌며, 입력한 내용을 확인해 오류 메시지를 보여주는 등의 동작도 DOM과 JavaScript의 상호작용을 통해 구현할 수 있다.
이 기능 자체는 정상적인 웹 개발의 기본 구조다.
문제는 신뢰할 수 없는 데이터가 안전하지 않은 방식으로 DOM에 삽입될 경우다.
공격자가 제어할 수 있는 문자열이 실행 가능한 코드나 HTML로 처리되면 DOM 기반 교차 사이트 스크립팅(DOM-based XSS)과 같은 취약점으로 연결될 수 있다.
따라서 클라이언트 사이드 보안은 외부 JavaScript만의 문제가 아니다.
웹사이트가 직접 작성한 JavaScript라도 사용자 입력이나 URL 등의 데이터를 잘못 처리하면 브라우저 내부에서 보안 문제가 발생할 수 있다.
제3자 스크립트와 공급망 위험
제3자 스크립트에는 또 다른 구조적 특징이 있다.
웹사이트 운영자가 코드를 직접 통제하지 않을 수 있다는 것이다.
예를 들어 사이트가 외부 CDN에서 JavaScript를 가져온다고 가정해 보자.
정상적인 상황에서는 다음과 같다.
Website
→ 외부 JavaScript 요청
→ 정상 파일 다운로드
→ Browser 실행
하지만 외부 서비스나 배포 경로가 침해돼 파일이 변경된다면 구조는 달라진다.
Website
→ 동일한 외부 JavaScript 주소 요청
→ 변경된 파일 다운로드
→ Browser 실행
웹사이트의 HTML이 수정되지 않았더라도 외부에서 가져오는 리소스가 변경될 수 있는 것이다.
이처럼 소프트웨어나 외부 구성요소의 공급 경로를 통해 최종 시스템까지 영향을 미치는 위험을 공급망 위험(Supply Chain Risk)이라고 한다.
웹에서는 JavaScript와 같은 제3자 리소스가 이러한 공급망의 일부가 될 수 있다.
콘텐츠 보안 정책(CSP)은 무엇인가
브라우저에서 실행될 수 있는 리소스를 제한하는 대표적인 웹 보안 기술이 콘텐츠 보안 정책(Content Security Policy, CSP)이다.
CSP는 웹사이트가 브라우저에
“이 페이지에서는 어떤 출처의 리소스를 가져오거나 실행할 수 있는가”
를 선언하는 정책이다.
예를 들어 JavaScript를 자사 도메인과 특정하게 허용한 서비스에서만 가져오도록 제한하거나 이미지, 스타일시트, iframe, 네트워크 연결 등의 출처를 각각 제어할 수 있다.
이를 개념적으로 표현하면 다음과 같다.
Web Page
→ CSP 전달
→ Browser가 정책 확인
→ 허용된 Resource → 로드 또는 실행
→ 허용되지 않은 Resource → 차단
현재 W3C의 Content Security Policy Level 3는 웹 개발자가 특정 페이지가 가져오거나 실행할 수 있는 리소스와 여러 보안 관련 정책을 제어할 수 있도록 하는 메커니즘을 정의한다.
하지만 CSP를 적용했다고 웹사이트의 모든 취약점이 사라지는 것은 아니다.
CSP는 취약한 코드를 자동으로 수정하는 기술이 아니라 허용되지 않은 리소스 실행 등을 제한하는 추가적인 보안 계층이다.
따라서 입력값 검증, 안전한 출력 처리, 애플리케이션 코드 자체의 보안과 별개의 계층으로 이해해야 한다.
SRI는 외부 파일이 바뀌었는지를 확인한다
CSP가 어디에서 리소스를 가져올 수 있는지를 통제하는 기술이라면 하위 리소스 무결성(Subresource Integrity, SRI)은 다른 질문을 다룬다.
“가져온 파일이 내가 예상했던 바로 그 파일인가?”
이다.
SRI는 JavaScript나 CSS와 같은 외부 리소스에 암호학적 해시(Cryptographic Hash)를 지정할 수 있도록 한다.
기본 구조는 다음과 같다.
개발자가 예상 파일의 Hash 지정
↓
Browser가 외부 Resource 다운로드
↓
다운로드한 Resource의 Hash 계산
↓
예상 Hash와 비교
↓
일치 → 사용
불일치 → 차단
따라서 같은 URL에서 파일을 가져오더라도 실제 파일 내용이 예상한 것과 달라지면 브라우저가 이를 확인할 수 있다.
W3C는 SRI를 사용자가 가져온 리소스가 예상하지 못한 방식으로 조작되지 않았는지를 브라우저가 검증할 수 있도록 하는 메커니즘으로 정의한다.
SRI의 첫 W3C Recommendation은 2016년에 발표됐으며, 관련 규격은 이후에도 발전하고 있다. W3C Web Application Security Working Group은 2026년에도 새로운 SRI Working Draft를 공개했다.
CSP와 SRI는 같은 기술이 아니다
두 기술은 함께 언급되는 경우가 많지만 역할이 다르다.
CSP의 핵심 질문은
“이 출처의 리소스를 허용할 것인가?”
이다.
SRI의 핵심 질문은
“이 파일이 예상했던 내용 그대로인가?”
이다.
예를 들어 example-cdn.com을 CSP에서 허용했다고 가정하자.
브라우저는 해당 출처에서 JavaScript를 가져오는 것을 허용할 수 있다.
하지만 그 파일 자체가 이전과 동일한지는 별개의 문제다.
SRI를 함께 사용하면 특정 외부 파일의 내용이 예상한 hash와 일치하는지도 검증할 수 있다.
따라서 두 기술은 서로 대체 관계가 아니라 서로 다른 문제를 다루는 보안 계층이다.
SRI에도 한계가 있다
SRI 역시 모든 클라이언트 사이드 문제를 해결하지 않는다.
가장 기본적인 특징은 예상하는 리소스의 내용을 사전에 특정해야 한다는 것이다.
외부 JavaScript가 업데이트될 때마다 파일 내용이 변경되는 서비스라면 hash 역시 달라진다.
따라서 자주 변경되는 외부 리소스에서는 SRI 관리가 복잡해질 수 있다.
또한 정상적인 파일 자체가 실행 과정에서 다른 외부 코드를 불러오거나 데이터를 전송하는 구조라면 단순히 최초 파일의 hash가 일치한다는 사실만으로 전체 실행 행동을 설명할 수 없다.
SRI는 리소스의 무결성(Integrity)을 검증하는 기술이지 해당 JavaScript가 수행하는 모든 행동이 안전하다는 것을 판정하는 기술은 아니다.
스크립트 목록 관리도 하나의 보안 통제가 된다
결제 산업에서는 브라우저에서 실행되는 JavaScript 자체를 별도의 관리 대상으로 다룬다.
PCI DSS v4.x의 Requirement 6.4.3은 결제 페이지에서 소비자의 브라우저에 로드되고 실행되는 스크립트와 관련해 승인 여부 확인, 무결성 보장, 필요한 이유를 포함한 스크립트 목록 관리 등을 요구한다.
Requirement 11.6.1은 결제 페이지의 스크립트 내용이나 보안에 영향을 주는 HTTP 헤더 등에 발생하는 무단 변경을 탐지하는 문제를 다룬다.
PCI Security Standards Council은 이러한 요구사항의 목적 중 하나가 소비자의 브라우저에서 결제 페이지가 렌더링될 때 승인되지 않은 코드가 실행되는 것을 방지하는 것이라고 설명한다.
여기서 중요한 것은 특정 보안 제품 하나를 사용하는지가 아니라
어떤 스크립트가 존재하는지
왜 필요한지
승인된 것인지
변경되지 않았는지
를 관리한다는 구조다.
즉 스크립트 인벤토리(Script Inventory) 자체가 클라이언트 사이드 보안의 한 구성요소가 될 수 있다.
클라이언트 사이드 보안은 하나의 기술로 완성되지 않는다
클라이언트 사이드 보안을 하나의 솔루션이나 보안 기능으로 이해하면 전체 구조를 설명하기 어렵다.
보호해야 하는 대상이 서로 다르기 때문이다.
Script Inventory
어떤 코드가 존재하는지를 파악한다.
↓
Authorization
실행되는 코드가 승인된 것인지 확인한다.
↓
Content Security Policy
어떤 출처와 종류의 리소스를 허용할 것인지 통제한다.
↓
Subresource Integrity
가져온 외부 리소스가 예상한 내용과 동일한지 확인한다.
↓
Secure Coding
DOM XSS와 같은 애플리케이션 코드 자체의 취약점을 줄인다.
↓
Change / Tamper Detection
기존 페이지나 스크립트에 예상하지 못한 변경이 발생했는지를 탐지한다.
↓
Runtime / Connection Monitoring
실제로 실행되는 코드가 어떤 행동을 하고 어떤 외부 시스템과 통신하는지를 관찰한다.
각 계층은 서로 다른 문제를 다룬다.
그래서 특정 기술 하나가 존재한다고 해서 나머지 계층이 자동으로 해결되는 것은 아니다.
클라이언트 사이드 보안의 핵심은 '브라우저에서 실제로 무엇이 실행되는가'다
웹사이트는 서버에서 만들어져 브라우저로 전달되지만 사용자가 실제로 경험하는 웹서비스는 브라우저에서 완성된다.
JavaScript가 실행되고 DOM이 변경되며 외부 서비스와 데이터가 오간다.
이 때문에 웹 보안에서도 서버가 전달한 파일만 확인하는 것과 사용자의 브라우저에서 최종적으로 어떤 코드가 실행되는지를 확인하는 것은 다른 문제다.
클라이언트 사이드 보안은 바로 이 지점을 대상으로 한다.
이를 구조적으로 정리하면 다음과 같다.
서버가 무엇을 보냈는가
와
브라우저가 무엇을 실행했는가
는 동일한 질문이 아니다.
클라이언트 사이드 보안은 두 번째 질문을 다루는 웹 보안 영역이다.
용어 정리
클라이언트 사이드(Client-Side)
웹서비스에서 사용자의 브라우저 등 클라이언트 환경에서 처리되는 영역.
서버 사이드(Server-Side)
웹서버나 애플리케이션 서버 등 서버 환경에서 코드가 실행되는 영역.
DOM(Document Object Model)
브라우저가 HTML 문서를 프로그램에서 접근하고 변경할 수 있는 객체 구조로 표현한 모델.
제3자 스크립트(Third-party Script)
웹사이트 운영 주체가 아닌 외부 서비스에서 제공하는 JavaScript.
클라이언트 사이드 공급망 위험(Client-side Supply Chain Risk)
웹페이지가 의존하는 외부 코드나 서비스의 공급 경로를 통해 최종 브라우저 실행 환경이 영향을 받을 수 있는 위험.
DOM 기반 교차 사이트 스크립팅(DOM-based XSS)
브라우저의 DOM 처리 과정에서 신뢰할 수 없는 데이터가 안전하지 않은 방식으로 처리돼 발생할 수 있는 XSS 유형.
콘텐츠 보안 정책(Content Security Policy, CSP)
웹페이지에서 어떤 리소스를 가져오거나 실행할 수 있는지 등을 브라우저에 선언하는 보안 정책.
하위 리소스 무결성(Subresource Integrity, SRI)
외부에서 가져온 리소스가 예상한 내용과 일치하는지 암호학적 hash를 이용해 브라우저가 확인할 수 있도록 하는 기술.
스크립트 인벤토리(Script Inventory)
웹페이지에서 사용되는 스크립트와 그 목적 등을 파악하고 관리하는 목록.
무결성(Integrity)
데이터나 코드가 승인되지 않은 방식으로 변경되지 않았음을 의미하는 보안 속성.
변조 탐지(Tamper Detection)
파일, 코드, 설정 등의 내용에 예상하지 못한 변경이 발생했는지를 확인하는 보안 통제.
심층 방어(Defense in Depth)
하나의 보안 수단에만 의존하지 않고 서로 다른 여러 보안 계층을 함께 사용하는 접근 방식.
출처
W3C Web Application Security Working Group — 「Content Security Policy Level 3」
웹페이지가 가져오거나 실행할 수 있는 리소스와 여러 보안 관련 정책을 제어하는 CSP의 기술 규격. 2026년 8월 13일 Working Draft가 공개돼 있다.
https://www.w3.org/TR/CSP/
W3C Web Application Security Working Group — 「Subresource Integrity」
브라우저가 가져온 외부 리소스가 예상하지 못하게 변경됐는지 검증할 수 있도록 하는 SRI 규격. 2016년 W3C Recommendation과 2026년 Working Draft가 존재한다.
https://www.w3.org/TR/sri/
OWASP Cheat Sheet Series — 「Content Security Policy Cheat Sheet」
CSP의 적용 구조와 보안상 역할, 한계를 설명하는 기술 자료.
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
OWASP Cheat Sheet Series — 「DOM based XSS Prevention Cheat Sheet」
브라우저의 DOM 처리 과정에서 발생할 수 있는 DOM 기반 XSS와 방어 원칙을 설명하는 기술 자료.
https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
PCI Security Standards Council — 「Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1」
결제 페이지에서 실행되는 스크립트의 승인·무결성·목록 관리와 변경 탐지에 관한 공식 가이드.