서드파티 쿠키와 브라우저 추적 방지

왜 브라우저가 막나

서드파티 쿠키는 광고·로그인·사기 탐지에도 쓰이지만, 한 도메인이 여러 사이트에 심은 ID로 사용자를 따라다니는 사이트 간 추적의 기본 도구다. 브라우저는 정당한 사용과 추적을 구별할 수 없으므로, 쿠키·저장소를 막거나 최상위 사이트별로 분할(partitioning) 하는 쪽을 택했다. 분할하면 같은 위젯이라도 a.example 안과 b.example 안에서 서로 다른 저장소를 보므로 사용자를 이을 수 없다.

분할 없음:

flowchart LR
  A["a.example 안에서"] --> W["widget.example 쿠키 1개"]
  B["b.example 안에서"] --> W
  W --> R["같은 값 → 추적 가능"]

분할:

flowchart LR
  A["a.example 안에서"] --> WA["(a.example, widget.example) 쿠키"]
  B["b.example 안에서"] --> WB["(b.example, widget.example) 쿠키"]
  WA -. "서로 못 봄" .- WB

이 차단은 사이트가 고를 수 없는 브라우저 정책이다. 서드파티 의존성이 막혀 초기화가 끝나지 않는 식으로 페이지가 깨질 수 있다.

브라우저별 현재 정책

시크릿·비공개 모드는 기본값이 더 엄격하고, 쿠키를 막으면 localStorage까지 막히기도 한다.

사파리 ITP의 세부 규칙

ITP(Intelligent Tracking Prevention)는 쿠키 차단 말고도 퍼스트파티 쪽 우회 수법을 함께 줄인다.

서버가 Set-Cookie로 심은 HttpOnly 퍼스트파티 쿠키가 로그인 상태를 가장 오래 안정적으로 유지한다. 클라이언트 저장소의 7일 제한은 Web Storage에도 영향을 준다.

크롬: 폐지 철회와 Privacy Sandbox 정리

크롬은 2020년부터 서드파티 쿠키를 없애고 대체 API(Privacy Sandbox)를 내놓겠다고 했지만 방향을 바꿨다.

그래서 "크롬에서는 서드파티 쿠키가 곧 사라진다"는 더는 사실이 아니다. 하지만 사파리·파이어폭스와 크롬 시크릿 창, 그리고 쿠키를 끈 크롬 사용자에게는 이미 막혀 있다. 서드파티 쿠키 없이 동작하는 설계가 여전히 기본값이다.

대응 1: CHIPS (Partitioned 쿠키)

임베드가 그 사이트 안에서만 상태를 유지하면 되는 경우(채팅 위젯, 지도 설정, 임베드 결제 세션)에 쓴다. 쿠키에 Partitioned를 붙이면 최상위 사이트별 저장소에 따로 담긴다.

Set-Cookie: __Host-widget_sid=34d8g; Secure; Path=/; SameSite=None; Partitioned

• 키는 (최상위 사이트, 쿠키를 심은 호스트) 쌍이다. 같은 위젯이 다른 사이트에 실리면 그 쿠키를 읽지 못한다.
• Secure가 필수다. 서브도메인끼리 공유할 필요가 없으면 __Host- 접두사를 붙인다. 교차 사이트 요청에 실려야 하므로 SameSite=None도 함께 준다.
• 같은 최상위 사이트의 서브도메인(shop.example, support.shop.example) 안에서는 계속 읽힌다.
• Baseline 2025다. 오래된 브라우저에서는 일반 쿠키처럼 다뤄지거나 무시될 수 있으므로 중요한 상태의 유일한 저장소로 삼지 않는다. 파이어폭스는 원래 서드파티 쿠키를 분할하지만, 브라우저 간 일관성을 위해 명시적으로 Partitioned를 쓰는 편이 낫다.

대응 2: Storage Access API

임베드가 분할되지 않은 자기 쿠키가 꼭 필요한 경우(다른 사이트에 실린 댓글·결제 위젯에서 기존 로그인 사용)에 쓴다. 사용자 동작을 받아 브라우저에 접근을 요청한다.

// 교차 사이트 iframe 안에서
if (!(await document.hasStorageAccess())) {
  button.addEventListener('click', async () => {
    try {
      await document.requestStorageAccess() // 클릭 같은 사용자 활성화가 필요
      location.reload()                      // 허용되면 쿠키를 싣도록 다시 불러온다
    } catch {
      showSignInPopup()                      // 거부되면 대체 흐름
    }
  })
}

사파리 ITP에서는 허용받은 도메인이 30일간 데이터 삭제에서 보호되기도 한다. 크롬의 Related Website Sets와 requestStorageAccessFor()는 은퇴 대상이므로 새로 쓰지 않는다.

설계 원칙

쿠키를 막으면 추적자는 쿠키 없는 식별, 즉 지문 채취로 옮겨 간다. 브라우저는 그것도 줄이고 있다.

정리

• 사파리는 서드파티 쿠키를 예외 없이 막고, 파이어폭스는 사이트별로 분할한다.
• 크롬은 폐지를 철회하고 사용자 설정에 맡기며, Privacy Sandbox는 CHIPS·FedCM·Private State Tokens만 남기고 정리했다.
• 임베드 상태는 Partitioned, 분할 안 된 쿠키가 꼭 필요하면 Storage Access API.
• 서드파티 쿠키에 기대는 로그인·결제 흐름은 어느 브라우저에서든 깨질 수 있다고 보고 설계한다.

관련 노트: 쿠키와 세션, Web Storage: localStorage와 sessionStorage, 서드파티와 프라이버시, 브라우저 지문 채취, OAuth 2.0, DevTools Application 패널