'동일 사이트' 및 '동일 출처'는 자주 인용되지만 잘못 이해되는 용어입니다. 예를 들어 페이지 전환, fetch()
요청, 쿠키, 팝업 열기, 삽입된 리소스, iframe과 관련하여 사용됩니다. 이 페이지에서는 두 개념의 정의와 차이점을 설명합니다.
출발지
![출발지](https://web.developers.google.cn/static/articles/same-site-same-origin/image/origin-scheme.png?authuser=19&hl=ko)
'출처'는 스키마(프로토콜(예: 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)](https://web.developers.google.cn/static/articles/same-site-same-origin/image/site-tld1-ae5ebbc587fbe.png?authuser=19&hl=ko)
.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)](https://web.developers.google.cn/static/articles/same-site-same-origin/image/site-etld1-2ffebe0e355bd.png?authuser=19&hl=ko)
'동일 사이트' 및 '크로스 사이트'
스키마와 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 | 동일 사이트: 포트는 중요하지 않음 |
'스키마 없는 동일 사이트'
![스키마 없는 동일 사이트](https://web.developers.google.cn/static/articles/same-site-same-origin/image/schemeless-same-site-3ba215c9666cd.png?authuser=19&hl=ko)
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로 수정할 수 없습니다.- 브라우저는 항상 이 제목을 설정합니다.