Fetch Metadata 헤더 기준 정리

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

Fetch Metadata 헤더 기준 정리

다른 사이트에서 보낸 요청을 서버가 구분하지 못하면 CSRF, XSSI, 교차 출처 정보 노출 같은 문제가 생길 수 있다. 2026년 6월 21일 기준 W3C Fetch Metadata Request Headers 작업 초안, MDN, web.dev 문서를 보면 브라우저는 Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-User 헤더로 요청의 맥락을 서버에 전달할 수 있고, 서버는 이 값을 바탕으로 요청을 초기에 차단할 수 있다.

실무에서 중요한 판단은 세 가지다. 내 서비스가 원래 자기 자신만 불러야 하는 리소스를 많이 갖고 있는지, 서브도메인과 외부 CORS 엔드포인트를 어디까지 신뢰할지, 그리고 정책 적용 전에 예외 경로를 얼마나 정확하게 정리했는지다. 이 글은 Fetch Metadata를 언제 유용하게 쓸 수 있는지와 안전한 기본 허용 기준을 짧게 정리한다.

Fetch Metadata 헤더는 무엇을 위한 기능일까?

W3C 초안은 Fetch Metadata 요청 헤더를 "요청이 어떤 방식으로 만들어졌고 어떤 맥락에서 쓰일지를 서버가 미리 판단할 수 있게 하는 정보"로 정의한다. 핵심은 애플리케이션 코드가 본격적으로 요청을 처리하기 전에, 프록시나 CDN 단계에서도 의심스러운 교차 사이트 요청을 거를 수 있다는 점이다.

web.dev는 이를 Resource Isolation Policy라는 방어 기법으로 설명한다. 원래 내 애플리케이션이 자기 자신의 문서와 스크립트 안에서만 불러야 하는 리소스라면, 다른 사이트가 그 리소스를 읽거나 로드하려는 요청을 차단하는 것만으로도 여러 교차 출처 공격의 표면을 줄일 수 있다.

각 헤더는 무엇을 알려줄까?

헤더	역할	대표 값
Sec-Fetch-Site	요청 시작점과 대상 리소스의 사이트 관계	same-origin, same-site, cross-site, none
Sec-Fetch-Mode	요청 모드	navigate, cors, no-cors, same-origin, websocket
Sec-Fetch-Dest	리소스 목적지	document, image, script, iframe, empty
Sec-Fetch-User	사용자 활성화가 있는 탐색인지 여부	?1

MDN과 W3C 문서를 같이 보면 서버에서 가장 먼저 보는 값은 대개 Sec-Fetch-Site다. 같은 origin인지, 같은 site인지, 완전히 다른 site인지가 1차 구분선이기 때문이다. 그다음에 Sec-Fetch-Mode와 Sec-Fetch-Dest로 이것이 탐색인지, 이미지나 스크립트 같은 하위 리소스 로드인지 세분화하는 흐름이 일반적이다.

same-origin, same-site, cross-site, none는 어떻게 해석해야 할까?

MDN에 따르면 same-origin은 스킴, 호스트, 포트까지 같은 경우이고, same-site는 같은 사이트이지만 origin까지 같지는 않을 수 있는 경우다. 예를 들어 app.example.com과 static.example.com 사이 요청은 정책에 따라 허용할 수도 있고 더 엄격하게 막을 수도 있다.

cross-site는 다른 사이트에서 온 요청이고, none은 주소창 입력이나 북마크 클릭처럼 사용자가 브라우저에서 직접 시작한 탐색을 뜻한다. W3C 초안도 직접적인 사용자 상호작용으로 시작된 navigation request에는 Sec-Fetch-Site: none을 설정하도록 설명한다.

어떤 요청을 기본 허용으로 보는 편이 무난할까?

web.dev가 제안하는 Resource Isolation Policy의 기본 흐름은 단순하다. 첫째, Fetch Metadata 헤더를 아예 보내지 않는 브라우저 요청은 호환성을 위해 우선 통과시킨다. 둘째, same-origin, same-site, none은 기본 허용한다. 셋째, 단순한 최상위 GET 탐색은 허용하되 object와 embed 같은 목적지는 제외한다. 마지막으로 그 밖의 교차 사이트 비탐색 요청은 거부한다.

다만 이 기본값이 언제나 맞는 것은 아니다. 서브도메인을 완전히 신뢰하지 않는 서비스라면 same-site도 막아야 할 수 있다. 반대로 외부에서 접근해야 하는 공개 이미지, CORS API, 결제 콜백 같은 엔드포인트는 경로 단위 예외가 필요하다.

if not sec_fetch_site:
    allow()
elif sec_fetch_site in ("same-origin", "same-site", "none"):
    allow()
elif sec_fetch_mode == "navigate" and method == "GET" and sec_fetch_dest not in ("object", "embed"):
    allow()
elif path in CROSS_SITE_ALLOWED_PATHS:
    allow()
else:
    reject_403()

 

 

왜 Vary 헤더까지 같이 봐야 할까?

W3C 초안의 배포 고려사항은 응답이 Fetch Metadata 헤더 값에 따라 달라진다면 적절한 Vary 헤더를 넣으라고 명시한다. 예를 들어 어떤 엔드포인트가 Sec-Fetch-Site에 따라 200과 403을 다르게 반환한다면 캐시가 이 차이를 구분해야 한다.

web.dev도 특히 GET 요청 보호가 목적이라면 서버의 Vary에 Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site를 포함하라고 안내한다. 이 부분을 빼면 프록시나 CDN 캐시가 정책이 다른 응답을 섞어 반환할 수 있다.

어떤 서비스에서 효과가 큰가?

상황	우선순위	이유
세션 쿠키 기반 웹앱	높음	교차 사이트 요청이 실제 상태 변경으로 이어질 가능성이 큼
내부 JSON, HTML 조각, 문서 다운로드 엔드포인트가 많은 서비스	높음	XSSI와 정보 노출 완화에 유리함
정적 파일 CDN 중심 서비스	중간	일부 공개 리소스는 예외 처리가 많이 필요할 수 있음
외부 임베드와 공개 API가 많은 플랫폼	중간 이하	효과는 있지만 예외 경로 설계 비용이 큼

web.dev는 Fetch Metadata가 현대 브라우저 엔진 전반에서 지원된다고 설명하고, MDN은 Sec-Fetch-Site를 2023년 3월부터 널리 사용 가능한 기능으로 표시한다. 다만 보안 정책은 "지원 여부"보다 "정상 트래픽이 정책을 얼마나 자주 벗어나는지"가 더 중요하므로, 실제 운영에서는 로깅과 점진 적용이 먼저다.

적용 전에 무엇을 점검해야 할까?

첫 번째는 교차 사이트로 열려 있어야 하는 경로 목록이다. 공개 이미지, 폰트, 파일 다운로드, CORS 허용 API, OAuth나 결제 리디렉션 복귀 경로처럼 외부 흐름과 연결되는 URL은 미리 구분해야 한다.

두 번째는 인증 전에 차단하는 순서다. web.dev는 민감한 타이밍 정보를 줄이기 위해 인증 검사나 무거운 애플리케이션 처리보다 먼저 부적합 요청을 거부하라고 권장한다. 즉 애플리케이션 코드 깊숙이 들어간 뒤 403을 주는 구조보다, 앞단 미들웨어나 프록시에서 빠르게 끊는 편이 낫다.

자주 헷갈리는 질문

Q. Fetch Metadata가 CSRF 방어를 완전히 대체할까?

아니다. Fetch Metadata는 방어 심화 수단에 가깝다. CSRF 토큰, SameSite 쿠키, 적절한 CORS 정책 같은 기존 방어와 함께 쓰는 편이 안전하다.

Q. same-site는 항상 믿어도 될까?

그렇게 단정하면 안 된다. 서브도메인을 여러 팀이나 외부 시스템이 공유하는 환경이라면 same-site도 충분히 공격 경로가 될 수 있다. 이 경우 web.dev가 제시한 기본 정책에서 same-site를 제외하는 쪽이 더 맞다.

Q. 모든 403을 바로 적용해도 될까?

운영에서는 먼저 로그를 수집하는 편이 안전하다. web.dev도 실제 서비스 트래픽에서 위반을 먼저 확인하고, 필요한 엔드포인트 예외를 정리한 뒤 강제로 전환하는 순서를 권장한다.

정리

Fetch Metadata 헤더는 "누가 어떤 맥락으로 이 요청을 보냈는가"를 서버가 빠르게 판단하게 해 주는 기능이다. 대부분의 웹앱에서는 same-origin, none, 필요할 때의 same-site만 허용하고, 나머지 교차 사이트 하위 리소스 요청은 차단하는 정책이 출발점이 된다.

2026년 6월 21일 기준 공개 문서를 기준으로 보면 핵심은 헤더 자체보다 정책 경계다. 어떤 경로가 외부에서 열려 있어야 하는지 먼저 분리하고, 응답이 달라지는 엔드포인트에는 Vary를 정확히 설정하는 것이 실제 운영 품질을 좌우한다.

참고 자료

• W3C Working Draft: Fetch Metadata Request Headers
• MDN: Sec-Fetch-Site header
• web.dev: Protect your resources from web attacks with Fetch Metadata