HAR 파일과 소스맵은 프로덕션 환경에서 실제 전송되는 리소스와 원본 소스 코드 사이를 잇는 연결 고리 역할을 합니다. 이 연결 고리 덕분에 블랙박스 분석 수준의 점검을 소스 코드 기반의 리뷰 수준으로 확장해 주기 때문에, 공격면 점검에서 빼놓기 어려운 부분입니다.
HAR 파일이 공격면 점검의 출발점이 되는 이유
웹 애플리케이션 보안 점검에서 브라우저와 서버 사이에 오가는 모든 네트워크 트래픽을 기록한 HAR(HTTP Archive) 파일은 활용 가치가 높은 데이터 소스입니다. 특히 단순한 요청 기록을 넘어 응답 본문(Response Body)까지 포함된 HAR 파일을 확보하면, 서버가 클라이언트로 전송한 JavaScript와 HTML 리소스를 로컬 환경에서 정밀하게 분석할 수 있게 됩니다.
그런데 실제 운영 환경의 JavaScript는 파일 크기를 줄이려고 공백을 제거하고 변수명을 축약하는 Minification 과정을 거칩니다. 이 상태의 코드는 가독성이 크게 떨어져 로직 분석에 시간이 많이 들고, 그만큼 공격자나 보안 점검자의 분석 비용이 올라갑니다. 이때 소스맵(Source Map) 파일이 함께 노출되어 있으면 사정이 다릅니다. 분석자는 압축된 코드를 원본 소스 코드로 역매핑해 공격면을 훨씬 수월하게 훑을 수 있습니다.
unhar 실전 절차: HAR 캡처부터 JS·HTML 추출까지
HAR 파일에서 리소스를 추출할 때는 unhar 같은 도구가 편합니다. 이 도구는 HAR 파일 안의 JavaScript와 HTML을 추출하면서 원래의 URL 폴더 구조를 그대로 보존해 줍니다.
HAR 파일 캡처 시 주의사항
리소스를 정상적으로 추출하려면 브라우저 개발자 도구(DevTools)의 네트워크 탭에서 그냥 HAR로 저장해서는 안 됩니다. 반드시 ‘Save all as HAR with content’ 옵션을 선택해야 합니다. 일반 HAR 형식으로 저장하면 응답 본문이 누락되어 실제 리소스 추출이 불가능하기 때문입니다.
unhar 실행 및 옵션 활용
unhar의 기본 실행 명령어는 다음과 같습니다.
python3 unhar.py site.har --output folder
분석 목적에 맞게 옵션을 조합해 쓰면 됩니다.
- 기본 실행: JavaScript/HTML 추출과 URL 구조 보존, 소스맵 검색 후 beautify/unminify 처리까지 수행합니다.
- 소스맵 검색 제외:
--no-srcmap옵션을 사용하면 소스맵 탐색 과정을 건너뜁니다. - 후처리 제외:
--no-beautify옵션을 사용하면 beautify 또는 deobfuscation 과정을 생략합니다. - 순수 추출:
--no-srcmap과--no-beautify를 함께 쓰면 후처리 없이 원본 리소스만 뽑아냅니다.
추출 과정에서 경로 단위가 기존 디렉터리와 충돌하면 해당 파일은 그 디렉터리 내부의 index.html로 저장되는 규칙이 적용됩니다. 다만 이 규칙이 모든 파일에 예외 없이 똑같이 적용되는지는 추가 확인이 필요합니다.
소스맵 자동 수집과 원본 소스 트리 복원 원리
소스맵 수집 전략
unhar는 소스맵을 찾을 때 폴백(Fallback) 전략을 따릅니다. 수집 단계는 이 순서로 진행됩니다.
sourcemapper -jsurl실행.<url>.map경로 요청.<url>.map.js경로 요청.- JavaScript 파일 내
//# sourceMappingURL=주석 확인 (data URI의 경우 base64 디코딩 수행).
복원 메커니즘: sources와 sourcesContent
소스맵 파일에는 Minified JavaScript를 원본 코드로 매핑하는 정보가 담겨 있습니다. 복원을 좌우하는 것은 내부의 두 가지 핵심 배열입니다.
- sources 배열: 원본 소스 파일의 경로 정보가 담겨 있습니다.
- sourcesContent 배열: 실제 원본 소스 코드가 포함되어 있습니다.
sourcemapper 같은 도구는 webpack이나 유사한 도구로 생성된 소스맵을 파싱해, 이 배열들에 담긴 경로와 내용을 기반으로 원본 JavaScript 파일과 소스 트리 구조를 그대로 재구성합니다. 물론 복원은 해당 소스맵 파일에 접근 권한이 있을 때만 가능합니다. 소스맵이 없거나 접근이 차단된 환경이라면 복원 범위가 줄어들고, 그만큼 공격면 점검의 해상도도 낮아집니다.
소스맵 노출이 드러내는 실질적 공격면
소스맵으로 원본 코드가 복원되면 블랙박스 테스트만으로는 발견하기 어려운 민감한 정보들이 드러납니다. 분석자의 시선이 ‘추측’에서 ‘검토’로 옮겨가는 순간입니다.
노출 가능한 주요 정보 유형
| 노출 항목 | 보안 영향 및 점검 포인트 |
|---|---|
| API 키 및 토큰 | 코드 내에 하드코딩된 인증 정보가 노출되어 권한 없는 API 호출 가능성 증가 |
| 숨겨진 관리 기능 | UI상으로는 보이지 않지만 소스 코드 내에 정의된 관리자 전용 함수나 페이지 경로 확인 |
| 미실행 API 엔드포인트 | 정상적인 서비스 이용 과정(클릭 등)으로는 도달하지 않는 숨겨진 API 경로 발견 |
| 개발자 주석 | 로직의 힌트나 잠재적 취약점, TODO 리스트 등 내부 구현 정보 노출 |
실제 노출 사례
소스맵을 제거하지 않아 대규모 소스 코드가 노출된 사고는 실제로 있었습니다. 2026년 3월 31일, npm 공개 패키지 배포 과정에서 소스맵 파일을 제외하지 않은 인적 실수로, 해당 소스맵이 가리키는 무인증 상태의 저장소로부터 약 1,906개의 TypeScript 파일, 총 51만여 줄의 소스 코드가 공개된 것이 확인되었습니다.
운영 환경 대응 및 보안 관점의 고찰
webpack을 이용한 소스맵 제어
webpack은 프로덕션 환경에서의 소스맵 노출을 devtool 옵션으로 제어합니다.
devtool: false: 소스맵을 전혀 생성하지 않습니다.hidden-source-map: 소스맵은 생성하지만 번들 파일에 참조 주석을 추가하지 않아, 브라우저 개발자 도구에서 자동으로 소스맵을 찾지 못하게 합니다. 에러 스택 트레이스 분석용으로만 활용할 때 유용합니다.nosources-source-map: 소스맵을 생성하되sourcesContent는 포함하지 않습니다. 매핑 정보는 있지만 실제 원본 코드는 담기지 않습니다.
소스맵 비노출의 보안적 의미
프로덕션 환경에서 소스맵을 노출하지 않으면 잠재적 공격자의 분석 비용이 높아져, 분석 과정이 ‘약간 더 어렵게(slightly harder)’ 되는 효과가 있습니다. 다만 이는 분석의 난이도를 높이는 것일 뿐, 코드 자체에 존재하는 취약점이 사라지는 것은 아닙니다. 공격자는 소스맵 없이도 JavaScript beautifier 등으로 코드를 분석해 내기 때문입니다.
소스맵 노출을 즉각적인 치명적 취약점으로 단정하기보다는, 조직의 위협 모델(Threat Model)에 따라 정보 노출의 허용 범위를 정하고, 공격자의 분석 비용 관점에서 대응 수준을 결정하는 편이 적절합니다.