'동일 사이트' 및 '동일 출처'

'동일 사이트' 및 '동일 출처'는 자주 인용되지만 잘못 이해되는 용어입니다. 예를 들어 페이지 전환, fetch() 요청, 쿠키, 팝업 열기, 삽입된 리소스, iframe과 관련하여 사용됩니다. 이 페이지에서는 두 개념의 정의와 차이점을 설명합니다.

출발지

출발지
출처의 구조.

'출처'는 스키마(프로토콜(예: HTTP 또는 HTTPS), 호스트 이름, 포트(지정된 경우))의 조합입니다. 예를 들어 URL이 https://www.example.com:443/foo이면 '출처'는 https://www.example.com:443입니다.

'동일 출처' 및 '교차 출처'

스키마, 호스트 이름, 포트의 조합이 동일한 웹사이트는 '동일 출처'로 간주됩니다. 그 밖의 모든 것은 '교차 출처'로 간주됩니다.

출처 A 출처 B '동일 출처' 또는 '교차 출처' 중 무엇인가요?
https://www.example.com:443 https://www.evil.com:443 교차 출처: 다른 도메인
https://example.com:443 교차 출처: 다른 하위 도메인
https://login.example.com:443 교차 출처: 다른 하위 도메인
http://www.example.com:443 교차 출처: 다양한 스키마
https://www.example.com:80 교차 출처: 다양한 포트
https://www.example.com:443 동일 출처: 완전 일치
https://www.example.com 동일 출처: 암시적 포트 번호 (443) 일치

사이트

사이트 (TLD+1)
URL에서 사이트를 구성하는 부분

.com.org과 같은 최상위 도메인 (TLD)루트 영역 데이터베이스에 나열됩니다. 위의
예에서 '사이트'는 스키마TLD, 바로 앞의 도메인 부분 (TLD+1이라고 함)의 조합입니다. 예를 들어 URL이 https://www.example.com:443/foo이면 '사이트'는 https://example.com입니다.

공개 접미사 목록 및 eTLD

.co.jp 또는 .github.io와 같은 요소가 있는 도메인의 경우 .jp 또는 .io를 사용하는 것만으로는 '사이트'를 식별할 수 있을 만큼 구체적이지 않습니다. 알고리즘에 따라 특정 TLD의 등록 가능한 도메인 수준을 결정하는 방법은 없습니다. 이를 위해 공개 접미사 목록유효 TLD (eTLD)이라고도 하는 공개 서픽스 목록을 정의합니다. eTLD 목록은 publicsuffix.org/list에서 유지관리됩니다.

eTLD를 포함하는 도메인의 '사이트' 부분을 식별하려면 .com의 예와 동일한 방식을 적용합니다. https://www.project.github.io:443/foo를 예로 들면, 스키마는 https이고, eTLD는 .github.io이고, eTLD+1은 project.github.io입니다. 따라서 https://project.github.io은 이 URL의 '사이트'로 간주됩니다.

사이트 (eTLD+1)
URL에서 eTLD를 포함하는 부분

'동일 사이트' 및 '크로스 사이트'

스키마와 eTLD+1이 동일한 웹사이트는 '동일 사이트'로 간주됩니다. 스키마가 다르거나 eTLD+1이 다른 웹사이트는 '크로스 사이트'라고 합니다.

출처 A 출처 B '동일 사이트' 또는 '크로스 사이트' 중 무엇을 사용해야 하나요?
https://www.example.com:443 https://www.evil.com:443 크로스 사이트: 서로 다른 도메인
https://login.example.com:443 동일 사이트: 하위 도메인이 다르더라도 상관없음
http://www.example.com:443 크로스 사이트: 다양한 체계
https://www.example.com:80 동일 사이트: 포트가 다르더라도 상관없음
https://www.example.com:443 동일 사이트: 일치검색
https://www.example.com 동일 사이트: 포트는 중요하지 않음

'스키마 없는 동일 사이트'

스키마 없는 동일 사이트

HTTP가 취약한 채널로 사용되지 않도록 사이트의 일부로 URL 스키마를 포함하도록 '동일 사이트'의 정의가 변경되었습니다. 스키마 비교가 없는 기존의 '동일 사이트' 개념은 이제 '스키마가 없는 동일 사이트'라고 합니다. 예를 들어 http://www.example.comhttps://www.example.com는 eTLD+1 부분만 중요하고 스키마는 고려되지 않으므로 스키마가 없는 동일 사이트로 간주되지만 동일 사이트는 아닙니다.

출처 A 출처 B '스키마 없는 동일 사이트' 또는 '크로스 사이트' 중 무엇을 사용해야 하나요?
https://www.example.com:443 https://www.evil.com:443 크로스 사이트: 서로 다른 도메인
https://login.example.com:443 스키마 없는 동일 사이트: 서로 다른 하위 도메인은 중요하지 않음
http://www.example.com:443 스키마 없는 동일 사이트: 여러 스키마는 중요하지 않음
https://www.example.com:80 스키마 없는 동일 사이트: 서로 다른 포트는 중요하지 않음
https://www.example.com:443 스키마 없는 동일 사이트: 일치검색
https://www.example.com 스키마 없는 동일 사이트: 포트는 중요하지 않음

요청이 '동일 사이트', '동일 출처' 또는 '크로스 사이트'인지 확인하는 방법

브라우저 지원

  • 76명
  • 79
  • 90
  • 16.4

소스

모든 최신 브라우저는 Sec-Fetch-Site HTTP 헤더를 사용하여 요청을 전송합니다. 헤더에는 다음 값 중 하나가 포함됩니다.

  • cross-site
  • same-site (스키마가 있는 동일 사이트 참조)
  • same-origin
  • none

Sec-Fetch-Site 값을 검사하여 요청이 동일 사이트, 동일 출처 또는 크로스 사이트인지 확인할 수 있습니다.

Sec-Fetch-Site 헤더의 값을 합리적으로 신뢰할 수 있습니다. 그 이유는 다음과 같습니다.