'동일 사이트' 및 '동일 출처'는 자주 언급되지만 종종 오해되는 용어입니다. 예를 들어 페이지 전환, 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) 일치 |
사이트

.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이 동일한 웹사이트는 '동일 사이트'로 간주됩니다. 스키마나 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 스키마를 포함하도록 'same-site' 정의가 변경되었습니다.
이전의 스키마 비교가 없는 '동일 사이트' 개념은 이제 '스키마 없는 동일 사이트'라고 합니다. 예를 들어 http://www.example.com
와 https://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 | 스키마 없는 동일 사이트: 포트는 중요하지 않음 |
요청이 '동일 사이트', '동일 출처' 또는 '교차 사이트'인지 확인하는 방법
모든 최신 브라우저는 Sec-Fetch-Site
HTTP 헤더를 사용하여 요청을 전송합니다.
헤더의 값은 다음 중 하나입니다.
cross-site
same-site
(스킴 기반 동일 사이트 참조)same-origin
none
Sec-Fetch-Site
값을 검사하여 요청이 동일 사이트, 동일 출처 또는 교차 사이트인지 확인할 수 있습니다.
다음과 같은 이유로 Sec-Fetch-Site
헤더의 값을 합리적으로 신뢰할 수 있습니다.
Sec-
로 시작하는 HTTP 헤더는 JavaScript로 수정할 수 없음- 브라우저는 항상 이러한 제목을 설정합니다.