텍스트 편집기에서 수동으로 파일을 삭제할 수 있나요?

할 수 있습니다 — HAR 파일은 JSON이고, 어떤 텍스트 편집기로도 열 수 있습니다 — 하지만 수동 삭제야말로 비밀이 살아남는 방법입니다: 같은 토큰이 헤더, 쿠키 목록, URL 문자열, 쿼리 매개변수에 나타나고, 사본 하나를 놓치면 자격 증명은 살아 남습니다. 나타나는 모든 곳에서 규칙에 따라 값을 대체하는 자동 처리가 지루하고 올바른 방법입니다. 어떤 방법으로 하든, 보내기 전에 완성된 파일에서, 들어 있다고 아는 각 비밀의 조각을 검색하세요.

삭제된 HAR가 지원 엔지니어에게 여전히 유용할까요?

네 — 그것이 항목을 지우는 대신 값을 삭제하는 의미입니다. 엔지니어는 요청 순서, 메서드, URL 형태, 헤더 이름, 상태, 크기, 시간을 유지합니다. 그것이 진단이 실제로 사용하는 것입니다; 잃는 것은 결코 필요하지 않았던 유효한 자격 증명 값뿐입니다. 엔지니어가 정말로 값을 봐야 한다면, 그것은 명시적으로 나눌 대화이며 — 보통 삭제된 파일로 충분하다는 동의로 끝납니다.

이미 원본 HAR 파일을 보냈습니다. 지금 무엇을 해야 하나요?

그 안의 세션을 공개된 것으로 취급하세요. 모든 곳에서 서비스에서 로그아웃하고(대부분의 서비스에는 캡처된 쿠키를 무효화하는 "모든 세션 로그아웃" 컨트롤이 있습니다), 다시 로그인하고, 캡처에 등장한 모든 API 키나 토큰을 교체하세요. 그런 다음 같은 티켓이나 스레드에 답장하여 첨부 파일 삭제를 요청하세요. 두 번째 삭제된 파일을 보내고 고쳐졌다고 여기지 마세요 — 삭제는 미래의 사본을 보호하는 것이지, 이미 전달된 사본을 보호하는 것이 아닙니다.

그 HAR 파일을 보내기 전에, 안에 무엇이 있는지 읽어 보세요

By John · Former Microsoft engineer with 20 years of experience.

"HAR 파일을 보내 주시겠어요?"는 합리적인 요청입니다 — 그리고 일상적인 지원 업무에서 가장 무심코 위험한 파일 전달 중 하나이기도 합니다. HAR 파일은 브라우저 세션의 완전한 기록입니다: 모든 요청과 응답을, 그것들을 동작하게 한 쿠키, 인증 헤더, 토큰, 양식 내용과 함께 기록합니다. 그것은 지원 엔지니어가 당신의 문제를 재현하는 데 필요한 바로 그것이며, 공격자가 당신의 세션을 재생하기 위해 원하는 바로 그것이기도 합니다. 이 글에서는 HAR 파일이 무엇인지, Chrome, Edge, Firefox에서 캡처하는 방법, 무엇이 새어 나가는지, 그리고 어디로 가기 전에 검사하고 삭제하는 방법을 설명합니다.

HAR 파일이란

HAR — HTTP Archive — 는 HTTP 트래픽을 기록하기 위한 JSON 형식으로, HAR 1.2 사양으로 표준화되었고 모든 주요 브라우저의 개발자 도구와 mitmproxy 같은 디버깅 프록시에서 내보낼 수 있습니다. 파일은 entries 배열을 가진 log 객체를 담고 있습니다: 요청마다 하나의 항목으로, 각각 메서드와 전체 URL, 요청 및 응답 헤더, 양방향 쿠키, 매개변수로 분해된 쿼리 문자열, 모든 POST 본문, 응답의 상태, 크기, 콘텐츠 유형, 그리고 단계별로 분해된 시간 — DNS, 연결, TLS, 전송, 대기, 수신 — 을 담습니다.

다시 말해, 그것은 문제의 스크린샷이 아닙니다; 그것은 문제 그 자체이며, 재생 가능합니다. HTTP 트래픽을 다루는 모든 것이 이 형식으로 동작합니다 — 브라우저 도구, 성능 분석기, 지원 엔지니어, 그리고 점점 더 에이전트까지: AI 에이전트가 당신의 앱을 리버스 엔지니어링할 수 있을까? 에서 다룬 REA 스택은 HAR 캡처를 네이티브로 읽습니다. 많은 앱에서는 API 트래픽이 코드보다 더 많은 것을 설명하기 때문입니다. 그 유용성이야말로 이 파일이 전송될 자격을 얻기 전에 읽힐 자격이 있는 이유입니다.

지원 팀과 공급업체가 요청하는 이유

논쟁을 끝내기 때문입니다. "페이지가 느렸다"는 이름이 붙은 요청과 시간을 가진 폭포가 됩니다. "API가 실패했다"는 정확한 페이로드와 정확한 헤더와 함께 500을 반환한 바로 그 요청이 됩니다. "내 컴퓨터에서는 된다"는 더 이상 중요하지 않습니다. 기록이 당신의 컴퓨터, 네트워크, 계정에서, 고장 난 바로 그 순간에 얻어진 것이기 때문입니다. 좋은 지원 엔지니어는 하나의 정직한 HAR 파일로 일주일치의 스크린샷과 기억보다 더 많은 일을 할 수 있습니다.

그래서 이 요청은 생각 없이 전달되는 경우도 많습니다. 티켓에는 "HAR를 첨부하세요"라고 적혀 있고, 사용자는 30초 만에 하나를 내보내며, 그 파일 — 로그인해서 실제 작업을 하는 동안 기록된 것 — 은 여행을 시작합니다: 티켓 시스템으로, 이메일 스레드로, 때로는 공개 포럼이나 공유 드라이브로, 이동할 때마다 사본을 축적하면서. 그 사슬에서 누구도 정확히 부주의한 것은 아닙니다; 형식이 그 내용을 숨길 뿐입니다. .har 파일은 비활성 진단 데이터처럼 보입니다. 실제로는 열쇠 뭉치에 더 가깝습니다.

Chrome, Edge, Firefox에서 캡처하는 방법

Chrome 또는 Edge에서는: 페이지를 열고 F12를 눌러 DevTools를 연 뒤 네트워크 패널로 이동합니다(Chrome DevTools 네트워크 참조가 모든 컨트롤을 문서화합니다). 빨간 녹화 버튼이 켜져 있는지 확인하고, 문제가 내비게이션에 걸쳐 있다면 로그 유지를 체크하세요. 문제를 처음부터 끝까지 한 번 재현합니다. 그런 다음 목록의 아무 요청이나 마우스 오른쪽 버튼으로 클릭하고 모두 HAR(콘텐츠 포함)로 저장을 선택합니다(Edge에서는 네트워크 로그 저장으로 표현됩니다). Firefox에서는 흐름의 형태가 같습니다: DevTools → 네트워크, 재현, 마우스 오른쪽 클릭 → 모두 HAR로 저장.

두 가지 캡처 습관은 어떤 설정보다 중요합니다. 첫째, 문제를 보여 주는 가장 짧은 세션을 기록하세요: 여분의 브라우징 1분마다 파일에 여분의 트래픽 — 그리고 여분의 비밀 — 이 늘어나며, 다른 탭과 백그라운드 요청이 그때 무엇을 하고 있었는지도 포함됩니다. 둘째, 가능하다면 새 브라우저 프로필이나 비공개 창에서, 해당 서비스에만 로그인한 채로 문제를 재현하세요. 깨끗한 프로필의 캡처에는 그 하나의 세션만 담기고 다른 것은 아무것도 담기지 않습니다: 은행 탭도, 웹메일도, 다른 앱의 토큰이 섞여 들어가는 일도 없습니다.

무엇이 새어 나가는가

무엇보다 당신의 세션입니다. Cookie 헤더와 Set-Cookie 헤더, 그리고 쿠키 목록에는 세션 식별자가 들어 있고, 대부분의 세션 쿠키는 가장 소박한 의미의 베어러 자격 증명입니다: 그것을 제시하는 사람은 만료되거나 취소될 때까지 당신으로 취급됩니다. Authorization 헤더는 베어러 토큰과 때로는 Basic 자격 증명을 더합니다. 형식 안의 무엇도 이 값들을 특별하다고 표시하지 않습니다; 그것들은 그저 헤더이며, 충실히 기록됩니다.

그다음, 아무도 헤더라고 생각하지 않는 것들. 토큰은 항상 URL에 숨어 있습니다 — API 키, 비밀번호 재설정 및 이메일 확인 링크, 서명된 다운로드 URL, OAuth 콜백 — 그리고 HAR는 전체 URL과 함께 쉽게 읽을 수 있도록 분해된 쿼리 문자열을 기록합니다. POST 본문은 양식이 실었던 것을 싣습니다: 캡처 중 로그인할 때 쓴 비밀번호, 프로필 편집, 메시지, 개인 데이터. 응답 본문은 같은 종류의 데이터를 돌려보낼 수 있습니다. 실제 세션의 HAR 파일은 사실상 당신 계정의 부분적인 기록입니다 — 그래서 네트워크에서 트래픽을 읽는 PCAP Analyzer 같은 도구와 브라우저에서 그것을 읽는 이 페이지 같은 도구는, 당신이 무엇을 들고 있는지 알 수 있도록 자격 증명을 명확히 보여 주도록 만들어진 것입니다.

보내기 전에 검사하고 삭제하세요

그러니: 다른 누구보다 먼저 파일을 여세요. 이 사이트의 HAR File Analyzer 가 바로 그 용도입니다 — .har를 페이지에 놓으면 로컬에서, 당신의 기기에서 파싱되고, 절대 업로드되지 않으며, 민감한 값은 기본적으로 마스킹됩니다: Authorization, Cookie, Set-Cookie 헤더, 모든 쿠키 값, 그리고 이름이 토큰, 키, 비밀, 세션, 비밀번호처럼 보이는 모든 헤더, 쿼리 매개변수, 양식 필드, JSON 키. 요약과 가장 느리고 가장 큰 요청을 훑어보고, 어떤 호스트가 나타나는지 확인하세요 — 캡처에는 당신이 보지도 않던 사이트의 트래픽이 들어 있을 때가 있습니다 — 그리고 정말 무엇이 들어 있는지 확인해야 한다면, 당신 자신의 화면에서만 "값 표시" 토글을 사용하세요.

그런 다음 삭제된 .har 를 다운로드해서 대신 보내세요. 삭제는 지원 엔지니어가 필요로 하는 구조 — 같은 항목, 헤더, 형태로서의 URL, 상태, 시간 — 를 유지하고, 자격 증명 값을 리터럴 텍스트 REDACTED 로 대체합니다. 헤더, 쿠키, 쿼리 문자열, 양식 데이터, JSON 본문 모두에서 똑같이요. 도구에도 인쇄되어 있고 여기서도 반복하는 한계 하나: JSON도 일반 양식 데이터도 아닌 POST 본문은 안전하게 파싱할 수 없어 그대로 유지됩니다 — 당신의 캡처에 그런 본문이 들어 있다면, 파일이 떠나기 전에 직접 읽어 보세요. 마스킹된 CSV 요약이 존재하는 것도 같은 이유입니다: 엔지니어가 "요청 목록만"을 요청할 때 첨부하는 파일입니다.

삭제가 할 수 없는 것

삭제는 열쇠를 제거합니다; 지도는 제거하지 않습니다. 삭제된 HAR는 여전히 당신의 호스트와 엔드포인트, 매개변수 이름, 응답의 형태와 크기, 호출의 순서와 시간을 보여 줍니다 — 당신 애플리케이션 API의 동작하는 스케치이며, 그 자체가 당신이 공개하지 않는 정보일 수 있습니다. 사본을 회수할 수도 없습니다: 원본 파일이 티켓 시스템이나 받은 편지함에 들어간 이상, 당신의 사본을 삭제해도 상대의 사본은 아무것도 바뀌지 않습니다. 삭제된 파일은 공급업체가 알려 준 비공개 채널 — 공개 게시물이나 공개 파일 링크가 아닌, 티켓 자체 — 로 공유하고, 티켓 안에서, 사례가 닫힐 때 파일 삭제를 요청하세요. 평판 좋은 지원 조직은 일상적으로 이렇게 합니다; 요청하는 데 비용은 들지 않습니다.

그리고 원본의, 삭제되지 않은 HAR가 이미 새어 나갔다면 — 잘못된 주소로 보내졌거나, 공개 이슈에 첨부되었거나, 공유 폴더에 남겨졌다면 — 세션을 노출된 것으로 취급하세요. 실제로 노출되었기 때문입니다: 서비스에서 로그아웃하고(보통 서버 측에서 세션이 무효화됩니다), 다시 로그인하고, 그 안에 등장한 모든 API 키를 교체하세요. 이것은 유출된 모든 자격 증명에 대한 것과 같은 규칙이며, 이 사이트의 다른 파일 도구들의 작은 글씨가 동일한 이유입니다 — Binary File Inspector 가 실행 파일을 로컬에서 읽는 것은 이 페이지가 캡처를 로컬에서 읽는 것과 같은 이유입니다: 검사가 가장 필요한 파일이야말로 검사를 위해 업로드해서는 안 되는 파일입니다.