'동일 사이트' 및 '동일 출처'는 자주 인용되지만 잘못 이해되는 용어입니다. 예를 들어 페이지 전환, 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 스키마를 포함하도록 '동일 사이트'의 정의가 변경되었습니다.
스키마 비교가 없는 기존의 '동일 사이트' 개념은 이제 '스키마가 없는 동일 사이트'라고 합니다. 예를 들어 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로 수정할 수 없습니다.- 브라우저는 항상 이 제목을 설정합니다.