'동일 사이트'의 정의 가 URL 스키마를 포함하도록 진화하고 있으므로 이제 사이트의 HTTP 버전과 HTTPS 버전 간의 링크는 크로스 사이트 요청으로 간주됩니다. 가능한 경우 문제를 방지하려면 기본적으로 HTTPS로 업그레이드하거나 필요한 SameSite 속성 값에 대한 자세한 내용을 읽어보세요.
스키마 주의 동일 사이트 (웹) 사이트의 정의를 등록 가능한 도메인에서 스키마 + 등록 가능한 도메인 자세한 내용과 예는 다음에서 확인할 수 있습니다. 'same-site' 이해 및 'same-origin'으로 확인하세요.
다행인 점은 웹사이트가 이미 HTTPS로 완전히 업그레이드되었다면 걱정할 필요가 없습니다 변경되는 사항은 없습니다.
아직 웹사이트를 완전히 업그레이드하지 않은 경우 이 작업을 우선시해야 합니다.
하지만 사이트 방문자가 HTTP와 HTTP를 번갈아 가며
HTTPS 후 몇 가지 일반적인 시나리오 및 관련 SameSite 쿠키
아래에 요약되어 있습니다
Chrome과 Firefox 모두에서 테스트를 위해 이러한 변경사항을 사용 설정할 수 있습니다.
- Chrome 86부터
about://flags/#schemeful-same-site를 사용 설정합니다. 진행 상황 추적 Chrome 상태 페이지를 참조하세요. - Firefox 79에서 다음을 통해
network.cookie.sameSite.schemeful를true로 설정합니다.about:config입니다. Bugzilla를 통해 진행 상황 추적 문제에 대해 자세히 알아보세요.
SameSite=Lax가 기본값으로 변경된 주된 이유 중 하나는
쿠키는 교차 사이트 요청 위조로부터 보호하기 위한 것이었습니다.
(CSRF) 하지만
안전하지 않은 HTTP 트래픽은 여전히 네트워크 공격자가
쿠키를 조작하여
사이트 스키마 사이에 이러한 추가 크로스 사이트 경계를 만들면
이러한 공격에 대한 추가 방어를 제공합니다
일반적인 교차 스키마 시나리오
탐색
웹사이트의 교차 스키마 버전 간 탐색 (예:
http://site.example에서 https://site.example로 변경)
쿠키가 SameSite=Strict개 전송됩니다. 이제 크로스 사이트로 처리됩니다.
탐색 시 SameSite=Strict 쿠키가 차단됩니다.
<ph type="x-smartling-placeholder">| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ 차단됨 | ⛔ 차단됨 |
SameSite=Lax
|
✓ 허용됨 | ✓ 허용됨 |
SameSite=None;Secure
|
✓ 허용됨 | ⛔ 차단됨 |
하위 리소스 로드
여기에서 변경한 내용은 완전한 HTTPS로 업그레이드할 수 없습니다
하위 리소스의 예로는 이미지, iframe, XHR 또는 Fetch를 사용합니다.
이전에는 교차 스키마 하위 리소스를 페이지에 로드하면
전송하거나 설정할 SameSite=Strict 또는 SameSite=Lax 쿠키입니다. 이제 이것이
해당 서비스가 제공되는 다른 제3자 또는 크로스 사이트 하위 리소스와 동일한 방식으로
SameSite=Strict 또는 SameSite=Lax 쿠키가 모두 차단됨을 의미합니다.
또한 브라우저에서 안전하지 않은 스키마의 리소스를
보안 페이지에 로드되면 이러한 요청에서 모든 쿠키가
서드 파티 또는 크로스 사이트 쿠키에는 Secure이(가) 필요합니다.
<ph type="x-smartling-placeholder">| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ 차단됨 | ⛔ 차단됨 |
SameSite=Lax
|
⛔ 차단됨 | ⛔ 차단됨 |
SameSite=None;Secure
|
✓ 허용됨 | ⛔ 차단됨 |
양식 게시하기
이전에는 웹사이트의 교차 스키마 버전 간에 게시하면
SameSite=Lax 또는 SameSite=Strict로 설정된 쿠키가 전송됩니다. 이제 이것이
크로스 사이트 POST로 취급되며 SameSite=None개의 쿠키만 전송할 수 있습니다. 다음을 수행할 수 있습니다.
기본적으로 안전하지 않은 버전을 제공하는 사이트에서
이 시나리오가 발생하는 경우
하지만 로그인 제출 시 사용자를 보안 버전으로 업그레이드하거나
결제 양식을 작성해 주시기 바랍니다.
하위 리소스와 마찬가지로 보안 리소스(예: HTTPS를
안전하지 않음(예: HTTP, 컨텍스트에서 해당 요청에서 모든 쿠키가 차단됩니다.
이는 서드 파티 쿠키 또는 크로스 사이트 쿠키에 Secure가 필요하기 때문입니다.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ 차단됨 | ⛔ 차단됨 |
SameSite=Lax
|
⛔ 차단됨 | ⛔ 차단됨 |
SameSite=None;Secure
|
✓ 허용됨 | ⛔ 차단됨 |
내 사이트를 테스트하려면 어떻게 해야 하나요?
Chrome과 Firefox에서 개발자 도구 및 메시지를 사용할 수 있습니다.
Chrome 86부터 Chrome OS의 문제 탭 DevTools는 Schemeful Same-Site 문제가 포함됩니다. 다음 문제가 강조표시될 수 있습니다. 생성합니다.
탐색 문제:
- "동일한 사이트에서 계속 쿠키를 보내려면 완전히 HTTPS로 마이그레이션해야 합니다. 요청' - 향후 버전에서 쿠키가 차단될 예정이라는 경고 Chrome의 기능을 살펴보세요.
- "동일 사이트 요청에서 쿠키를 전송하도록 완전히 HTTPS로 마이그레이션"—A 쿠키가 차단되었다는 경고 메시지가 표시됩니다.
하위 리소스 로드 문제:
- "동일한 사이트로 쿠키를 계속 전송하려면 완전히 HTTPS로 마이그레이션해야 합니다. 하위 리소스' 또는 '쿠키를 계속 허용하여 HTTPS를 사용하도록 완전히 HTTPS로 마이그레이션 동일 사이트 하위 리소스로 설정될 수 있음' - 쿠키가 삭제될 것이라는 경고 향후 버전의 Chrome에서 차단됩니다.
- "쿠키가 동일 사이트 하위 리소스로 전송되도록 완전히 HTTPS로 마이그레이션하세요." 또는 '동일한 사이트에서 쿠키를 설정하도록 완전히 HTTPS로 마이그레이션 subresources': 쿠키가 차단되었다는 경고입니다. 후자 양식을 게시할 때도 경고가 표시될 수 있습니다.
자세한 내용은 스킴을 위한 테스트 및 디버깅 도움말에서 확인할 수 있습니다. Same-Site로 구성됩니다.
Firefox 79에서, 다음을 통해 network.cookie.sameSite.schemeful을 true(으)로 설정
about:config Schemeful Same-Site 문제에 관한 메시지가 콘솔에 표시됩니다.
사이트에 다음과 같이 표시될 수 있습니다.
- '
cookie_name쿠키가 곧 크로스 사이트 쿠키로 처리됩니다. 스키마가 일치하지 않으므로http://site.example/입니다.' - '
cookie_name쿠키가 다음에 대해 크로스 사이트로 처리되었습니다. 스키마가 일치하지 않으므로http://site.example/입니다.'
FAQ
사이트가 이미 HTTPS에서 완벽하게 제공되는데 브라우저의 DevTools에 문제가 발생하는 이유는 무엇인가요?
일부 링크와 하위 리소스가 여전히 안전하지 않은 페이지로 연결될 수 있습니다. URL을 클릭합니다.
이 문제를 해결하는 한 가지 방법은 HTTP
엄격한 전송 보안
(HSTS) 및 includeSubDomain 지시어. HSTS + includeSubDomain 사용
페이지 중 하나에 안전하지 않은 링크가 실수로 포함되면 브라우저에서
대신 보안 버전을 자동으로 사용합니다.
HTTPS로 업그레이드할 수 없는 경우 어떻게 해야 하나요?
사이트를 완전히 HTTPS로 업그레이드하여 사용자를 보호할 수 없습니다. 그렇게 할 수 없는 경우 해당 옵션을 제공할 수 있는지 확인하세요. 직접 호스팅하는 경우 Let's Encrypt는 데이터를 암호화하고 인증서를 설치 및 구성할 수 있습니다 사이트 이동을 조사할 수도 있습니다. 다른 프록시로 연결된 네트워크 트래픽을 전송할 수 있습니다
그렇게 할 수 없는 경우 SameSite 보호를 완화해 보세요.
영향을 받은 쿠키입니다.
SameSite=Strict개의 쿠키만 차단되는 경우 보호 조치를Lax로 설정합니다.Strict및Lax쿠키가 모두 차단되고 보안 URL로 전송되거나 보안 URL에서 설정되는 경우 보호 기능을None로 설정합니다.- 이 해결 방법은 쿠키를 전송할 URL이 실패합니다 (또는
안전하지 않습니다.
SameSite=None에서 쿠키에Secure속성이 포함되어 있기 때문에 해당 쿠키가 전송되거나 보안되지 않은 연결을 통해 설정되는 것을 방지할 수 있습니다. 이 경우 해당 쿠키를 다시 사용 설정할 수 없습니다. - 결국에는 서드 파티 쿠키가 완전히 단계적으로 중단될 수 있습니다
- 이 해결 방법은 쿠키를 전송할 URL이 실패합니다 (또는
안전하지 않습니다.
SameSite 속성을 지정하지 않은 경우 쿠키에 어떤 영향을 주나요?
SameSite 속성이 없는 쿠키는
SameSite=Lax 및 동일한 교차 스키마 동작이
있습니다. 안전하지 않은 메서드에 대한 임시 예외가 계속 적용됩니다.
Chromium의 Lax + POST 완화 SameSite
FAQ를 참조하세요.
WebSocket은 어떤 영향을 받나요?
WebSocket 연결이 동일한 경우 여전히 동일한 사이트로 간주됩니다. 보안을 페이지로 사용합니다.
동일 사이트:
https://의wss://연결http://의ws://연결
크로스 사이트:
http://의wss://연결https://의ws://연결
사진: Julissa 캡데빌라 의 스플래시 해제