폼은 정상인데, 제출 뒤 생긴 요청은 본 적 없다면
회원가입 전환을 측정하려고 광고 픽셀을 붙이고, 문의 과정을 개선하려고 세션 리플레이를 켭니다. 폼도 잘 제출되고 이벤트도 쌓이니 별문제가 없어 보이죠. 하지만 이메일과 비밀번호를 입력한 순간 어떤 외부 요청이 생겼는지 확인하지 않았다면, 폼의 작동 여부만으로 데이터 전송 범위까지 판단할 수는 없습니다.
보안업체 Melurna의 테스트에 따르면 클라비요 가입 폼은 적어도 2024년 2월부터 2025년 11월까지 잘못 구성돼 있었습니다. 이메일·비밀번호·회사명·웹사이트 주소·전화번호가 페이지에 삽입된 Facebook, Google, HubSpot, Microsoft, LinkedIn, X 등의 외부 추적 업체와 공유될 수 있는 상태였어요. 다만 공개 자료에는 정확히 어떤 코드나 설정이 원인이었는지, 각 업체가 어떤 필드를 실제로 수신·저장했는지는 나오지 않았습니다.
클라비요는 문제를 수정하고 영향받은 이용자에게 통지했다고 밝혔습니다. 알려진 영향 인원은 ‘즉시 이용 가능한 활성 로그’를 기준으로 200명 미만이었지만, 로그 보존 기간이 공개되지 않아 전체 기간의 피해 규모로 일반화할 수는 없어요.
첫 확인은 네트워크 감사에서 시작합니다
별도 서비스 가입이나 API 인증은 필요하지 않습니다. Chrome과 내장 DevTools, 조직이 소유하거나 명시적으로 테스트를 허가한 폼이 있으면 시작할 수 있어요. 아래 입력값은 형식을 보여주기 위한 예시입니다. 실제 고객 정보나 다른 계정에서 사용하는 비밀번호를 넣지 말고, 조직이 관리하는 테스트 주소와 폼 검증 규칙에 맞는 값으로 바꾸세요.
예시 테스트값
- 이메일: qa+form-audit-20260907@example.test
- 가짜 비밀번호: WR-AUDIT-ONLY-9f3K!2
example.test가 실제 폼의 이메일 인증을 통과하지 못한다면 조직이 관리하는 수신 가능한 테스트 주소를 사용하세요. 제출이 완료되지 않으면 제출 후 실행되는 태그도 평가할 수 없습니다.
- 공식 절차와 준비 상태를 확인합니다.
Chrome Network 공식 문서의 요청 기록, Preserve log, 요청 검색 부분을 열어두세요. Chrome 외에 설치할 도구나 로그인할 서비스는 없습니다. 테스트 대상 폼, 동의 상태, 로그인 여부와 지역 조건을 재현할 권한도 확인합니다. - 기록을 비우고 Preserve log를 켭니다.
폼을 Chrome에서 연 뒤 DevTools의 Network 패널로 이동합니다. 녹화 표시가 활성화됐는지 확인하고 기존 요청을 지운 다음 Preserve log를 선택하세요. 이 설정은 제출 후 다른 페이지로 이동해도 이전 페이지의 요청을 남깁니다. 단, DevTools를 열기 전에 끝난 요청까지 소급해 기록하지는 않습니다. - 고유한 테스트값으로 제출을 완료합니다.
조직이 관리하는 테스트 이메일과 실제 서비스에서 재사용하지 않는 가짜 비밀번호를 입력합니다. 제출 버튼을 누른 뒤 성공 화면이나 성공 응답까지 확인하고 시각과 동의·로그인·지역 조건을 기록하세요. 검증 오류가 났다면 그 시나리오는 완료된 테스트로 세지 않습니다. - 일반 Filter가 아니라 Search 탭을 엽니다.
Network 패널에 포커스를 둔 상태에서 macOS는 Command+F, Windows·Linux는 Control+F를 누르세요. 오른쪽에 열린 Search 탭에 테스트 이메일·전화번호·가짜 비밀번호를 하나씩 입력하고 Enter를 누릅니다. 화면 위쪽 Filter 입력란은 도메인이나 메서드 같은 요청 속성을 거르는 곳이며, 전체 Payload 문자열을 찾는 검색창이 아닙니다. - 일치 요청의 목적지와 발생 경로를 기록합니다.
각 검색 결과를 눌러 목적지 URL과 Headers·Payload·Response를 확인하고, 요청 목록의 Initiator에서 어떤 스크립트가 요청을 만들었는지 추적하세요. HAR에는 인증 토큰이나 개인정보가 포함될 수 있으므로 일반 메신저나 공개 업무 저장소에 올리지 않습니다. - 원문이 없어도 제3자 요청과 태그 설정을 대조합니다.
제출 전후에 새로 생긴 외부 도메인 요청을 살피고, GTM·광고 태그·CMP에서 자동 수집, 사용자 제공 데이터, CSS 선택자와 해싱 기능이 켜져 있는지 확인하세요. Google Ads 향상된 전환은 이메일·이름·주소·전화번호 같은 퍼스트파티 데이터를 수집해 해시 형태로 Google에 보낼 수 있어 원문 검색만으로 발견되지 않을 수 있습니다. - 승인 여부를 판정하고 전송 경로를 제한합니다.
원문이나 확인 가능한 변환값이 발견되면 목적지, 캠페인 목적, 동의 조건, 적용 제품과 내부 승인을 대조하세요. 해시값이라는 이유만으로 유출이라고 단정할 수는 없지만, Google Analytics로 향하는 이메일·개인 전화번호 등의 PII는 전송 전에 제거해야 합니다. URL·페이지 제목과 폼 입력값에 섞인 PII도 점검 대상입니다. - 수정 후 같은 조건으로 다시 제출합니다.
Preserve log 설정부터 동일하게 반복하세요. 제출 성공이 기록됐고, 승인되지 않은 목적지에서 테스트값의 원문이나 확인 가능한 변환값이 발견되지 않으며, 태그 설정에도 해당 필드를 수집하는 승인되지 않은 경로가 없을 때 해당 시나리오의 첫 점검을 통과한 것으로 기록합니다.
검색 결과 없음은 곧 안전이라는 뜻이 아닙니다.
값이 정규화·해시·인코딩되거나 여러 필드로 나뉘면 원문 검색에 나타나지 않을 수 있습니다. 태그 설정을 볼 권한이 없다면 ‘미발견’으로 기록하고, 완전한 판정은 보류하세요.
dataLayer는 전송 목록이지 보안 경계가 아닙니다
같은 페이지에서 실행되는 제3자 JavaScript는 DOM에서 이용 가능한 데이터를 읽을 수 있습니다. 허용한 값만 dataLayer에 넣어도 일반 제3자 코드의 DOM 접근이 자동으로 차단되는 것은 아니에요. 실제 범위는 iframe 격리, 샌드박스와 태그 관리자 설정에 따라 달라집니다.
브라우저에서 해당 스크립트를 제거할 수 있다면 호스트가 값을 검증한 뒤 필요한 데이터만 서버 측 전달 경로로 보내는 구조를 검토할 수 있습니다. 클라이언트 태그를 유지해야 한다면 불필요한 DOM 변수와 Custom HTML을 줄이고, 템플릿 권한·선택자·자동 수집 범위를 제한하세요.
GTM에서는 컨테이너 권한이 Read·Edit·Approve·Publish로 나뉩니다. 태그를 수정할 사람과 운영에 게시할 사람을 구분하되, 권한 분리만으로 이미 배포된 태그의 수집 범위가 검증되는 것은 아니라는 점도 기억해야 합니다.
세션 리플레이는 현재 설정과 변경 시점을 봅니다
세션 리플레이 도구는 제품과 설정마다 마스킹 범위가 다릅니다. Microsoft Clarity는 현재 모든 마스킹 모드에서 입력 상자와 드롭다운을 가리고, 기본 Balanced 모드에서는 숫자와 이메일도 민감 콘텐츠로 분류합니다.
Clarity를 쓴다면 Settings → Masking에서 현재 모드를 확인하고, 추가로 가릴 컨테이너를 CSS 선택자나 data-clarity-mask 속성으로 지정하세요. 변경은 과거 기록에 소급되지 않고 새 기록에 반영되기까지 최대 1시간이 걸릴 수 있습니다. Clarity의 마스킹이 다른 광고·분석 태그의 전송까지 막아주는 것도 아닙니다.
새 태그가 붙을 때마다 같은 질문을 반복하세요
추적 기술을 통한 민감정보 공유는 클라비요만의 단발 사례가 아닙니다. 미국 FTC는 GoodRx가 처방약과 건강 상태 같은 정보를 Facebook과 Google 등의 광고 플랫폼에 수년간 공유했다고 주장했습니다. Princeton 연구진도 세션 리플레이가 관찰된 8,000개 사이트 목록과 Walgreens의 처방 정보, Gradescope의 학생 정보 사례를 공개했습니다.
각 사건의 기술 구성과 데이터 종류, 기간과 법적 지위는 서로 다릅니다. 같은 결함이나 하나의 피해 규모로 합칠 수는 없어요. 반복되는 운영 문제는 새 태그가 추가된 뒤 실제 전송 필드와 실행 조건을 다시 검사했는가입니다.
캠페인 변경 기록에 함께 남길 항목
- 태그 요청자와 업무 목적
- 실행되는 폼과 동의·로그인·지역 조건
- 외부 목적지와 승인된 원문·정규화·해시 필드
- 제출 성공 여부와 Network Search 결과
- 자동 수집·선택자·사용자 제공 데이터 설정
- 중단·수정·게시 권한을 가진 담당자
실제 개인정보가 승인되지 않은 목적지로 전송되는 것을 발견했다면 재현 범위를 무작정 넓히지 마세요. 먼저 태그나 전송 경로를 제한하고 증적 접근을 통제한 뒤, 보안·개인정보·법무 담당자와 사고 대응 및 통지 필요성을 검토해야 합니다.
