Clear-Site-Data 헤더 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Clear-Site-Data 헤더 기준 정리

Clear-Site-Data는 로그아웃, 계정 전환, 민감 정보 초기화처럼 브라우저에 남은 데이터를 정리해야 할 때 검토하는 HTTP 응답 헤더다. 2026년 6월 28일 기준 MDN과 W3C Clear Site Data 문서를 보면 이 헤더는 HTTPS 응답에서 캐시, 쿠키, DOM 스토리지, 실행 중인 문맥 재로딩을 브라우저에 지시할 수 있다.

실무에서 중요한 판단은 세 가지다. 정말 전체 정리가 필요한 상황인지, 어떤 데이터 타입만 지울지, 그리고 로그아웃 응답에서 새 쿠키를 다시 심는 흐름과 충돌하지 않는지다. 이 글은 공개 문서 기준으로 Clear-Site-Data를 언제 쓰고 어디서 조심해야 하는지 짧게 정리한다.

Clear-Site-Data는 언제 필요한가?

이 헤더는 브라우저가 이전 세션의 흔적을 강하게 비워야 하는 상황에서 의미가 있다. 대표적으로 로그아웃 직후 인증 쿠키와 저장소를 함께 지우는 경우, 공유 PC에서 민감 데이터를 남기지 않으려는 경우, 계정 전환 뒤 이전 사용자 캐시와 저장소를 섞지 않으려는 경우가 있다.

반대로 단순히 응답 캐시만 제어하고 싶다면 Cache-Control이 먼저다. Clear-Site-Data는 "앞으로 캐시하지 말라"가 아니라 "이미 저장된 사이트 데이터를 비워라"에 가깝다.

어떤 값을 넣을 수 있을까?

지시어	의미	주로 검토하는 상황
"cache"	브라우저 캐시 등 origin 관련 캐시 데이터 제거	이전 사용자 화면이나 상태가 캐시에 남으면 안 될 때
"cookies"	쿠키와 HTTP 인증 자격 증명 제거	로그아웃, 세션 강제 만료
"storage"	localStorage, sessionStorage, IndexedDB, 서비스 워커 등록 등 제거	오프라인 데이터나 클라이언트 저장소를 함께 비워야 할 때
"executionContexts"	해당 origin을 렌더링 중인 문맥을 다시 로드	메모리에 남은 상태를 새로 고쳐야 할 때
"*"	지원되는 전체 데이터 타입 정리	부분 선택보다 전체 초기화가 명확할 때

MDN은 현재 문서에서 "clientHints", "prefetchCache", "prerenderCache"도 소개하지만, 실제 운영 판단에서는 우선 위 표의 핵심 값들을 이해하는 편이 중요하다. 특히 헤더 값은 반드시 큰따옴표로 감싸야 하며, 따옴표가 없으면 유효하지 않다.

HTTPS가 아니면 왜 동작을 기대하면 안 될까?

W3C 문서는 응답 URL이 a priori authenticated URL이 아니면 정리 알고리즘을 중단하도록 정의한다. 실무적으로는 HTTPS가 아닌 응답에서 이 헤더를 보내도 기대한 정리가 일어나지 않을 수 있다는 뜻이다.

따라서 내부 테스트든 운영 환경이든 Clear-Site-Data는 HTTPS 전제를 깔고 설계하는 편이 맞다. 로컬 개발 환경에서 동작이 다르게 보인다면 먼저 전송 경로와 브라우저 지원 범위를 확인해야 한다.

로그아웃에는 어떤 조합이 무난할까?

대부분의 웹 서비스에서 로그아웃 응답은 "cookies"와 "storage"를 기본 검토 대상으로 본다. 자동 로그인 흔적이나 사용자별 저장 상태가 남으면 안 되는 서비스라면 "cache"까지 함께 고려할 수 있다.

다만 W3C 문서는 Set-Cookie 처리가 먼저 일어난 뒤 Clear-Site-Data가 적용된다고 설명한다. 즉 같은 로그아웃 응답에서 새 쿠키를 심어 두고 "cookies"를 같이 보내면 그 쿠키도 함께 지워질 수 있다. 로그아웃 후 새 상태 쿠키가 필요하면 후속 응답에서 다시 설정하는 흐름이 더 안전하다.

 

 

"cookies"만 지우면 끝일까?

항상 그렇지는 않다. MDN은 "cookies"가 응답 origin의 등록 도메인 전체와 하위 도메인까지 영향을 줄 수 있다고 설명한다. 하지만 쿠키만 비워도 localStorage나 IndexedDB에 남은 사용자 데이터는 그대로일 수 있다.

그래서 SPA나 오프라인 저장을 쓰는 서비스라면 "cookies" 단독보다 "storage"를 함께 검토하는 편이 현실적이다. 반대로 여러 서브도메인이 쿠키를 공유하는 환경에서는 "cookies"의 파급 범위를 먼저 점검해야 한다.

와일드카드 "*"는 편한 기본값일까?

W3C 문서는 전체 정리가 목적일 때는 "*"를 써도 되지만, 단지 네 가지 핵심 값을 줄여 쓰는 약어로 이해하지 말라고 적고 있다. 앞으로 데이터 타입이 늘어나면 와일드카드가 포함하는 범위도 함께 넓어질 수 있기 때문이다.

즉 서비스 요구사항이 "정말 전체 초기화"라면 "*"가 맞고, 아니면 필요한 지시어만 명시하는 편이 변경 영향이 더 예측 가능하다.

적용 전에 무엇을 확인해야 할까?

확인 항목	왜 필요한가	실무 기준
HTTPS 응답 여부	비보안 맥락에서는 동작을 기대하기 어려움	운영 적용 전 실제 배포 경로에서 확인
저장소 사용 범위	쿠키 외 데이터가 남을 수 있음	IndexedDB, 서비스 워커, localStorage 사용 여부 점검
서브도메인 영향	쿠키 삭제 범위가 넓을 수 있음	공유 인증 구조가 있으면 사전 검토
후속 세션 처리	같은 응답에서 심은 쿠키가 지워질 수 있음	로그아웃 후 리다이렉트 또는 다음 응답에서 재설정

MDN은 이 헤더를 2023년 9월 이후 여러 브라우저에서 넓게 사용할 수 있는 기능으로 표시하지만, 세부 데이터 타입마다 지원 차이가 있을 수 있다고 함께 안내한다. 따라서 최신 브라우저 중심 서비스인지, 구형 환경까지 포함하는지도 같이 봐야 한다.

자주 헷갈리는 질문

Q. Cache-Control: no-store와 같은 역할일까?

아니다. Cache-Control은 캐시 저장과 재사용 정책을 제어하고, Clear-Site-Data는 이미 저장된 사이트 데이터를 지우도록 지시한다.

Q. 로그인 응답에도 써야 할까?

일반적으로는 로그아웃이나 계정 초기화 같은 정리 시점에 더 잘 맞는다. 로그인 직후에는 기존 세션 데이터와 충돌하지 않는지, 새로 설정한 쿠키를 같은 응답에서 다시 지우지 않는지 먼저 검토해야 한다.

Q. 모든 로그아웃에 "*"를 넣는 편이 안전할까?

안전하다고 단정하기는 어렵다. 전체 초기화가 명확한 요구사항일 때는 적합하지만, 서비스 워커나 캐시까지 모두 비우면 사용성 영향이 커질 수 있다. 필요한 범위를 명시하는 편이 운영 영향 예측에는 유리하다.

정리

Clear-Site-Data는 브라우저에 남은 세션 흔적을 서버가 응답 헤더로 정리하도록 지시하는 기능이다. 실무에서는 로그아웃이나 계정 전환처럼 상태 정리가 핵심인 시점에 검토하고, "cookies"만이 아니라 "storage", "cache" 필요 여부까지 함께 판단하는 편이 맞다.

2026년 6월 28일 기준 공개 문서를 기준으로 보면 무난한 적용 순서는 HTTPS 전제 확인, 실제 저장소 사용 범위 파악, 로그아웃 응답의 쿠키 재설정 흐름 점검, 그리고 필요한 지시어만 좁게 선택하는 것이다. 특히 와일드카드는 편의상 쓰기보다 전체 초기화 의도가 분명할 때만 선택하는 편이 안전하다.

참고 자료

• MDN: Clear-Site-Data header
• W3C: Clear Site Data