스키마가 있는 Same-Site

'동일 사이트'의 정의가 URL 스키마를 포함하도록 진화하고 있으므로 이제 사이트의 HTTP 버전과 HTTPS 버전 간의 링크는 교차 사이트 요청으로 간주됩니다. 가능한 경우 기본적으로 HTTPS로 업그레이드하여 문제를 방지하거나 SameSite 속성 값에 필요한 사항에 관한 자세한 내용을 읽어보세요.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

스키마가 포함된 Same-Site (웹)사이트의 정의를 등록 가능한 도메인에서 스키마 + 등록 가능한 도메인으로 수정합니다. '동일 사이트' 및 '동일 출처' 이해 에서 자세한 내용과 예를 확인할 수 있습니다.

좋은 소식은 웹사이트가 이미 HTTPS로 완전히 업그레이드된 경우 아무것도 걱정할 필요가 없다는 것입니다. 아무것도 변경되지 않습니다.

아직 웹사이트를 완전히 업그레이드하지 않은 경우 이를 우선순위로 지정해야 합니다. 하지만 사이트 방문자가 HTTP와 HTTPS 간에 이동하는 경우가 있다면 이 도움말의 뒷부분에서 이러한 일반적인 시나리오와 연결된 SameSite 쿠키 동작을 설명합니다.

Chrome과 Firefox 모두에서 테스트를 위해 이러한 변경사항을 사용 설정할 수 있습니다.

쿠키의 기본값으로 SameSite=Lax로 변경한 주요 이유 중 하나는 크로스 사이트 요청 위조(CSRF)로부터 보호하기 위해서입니다. 하지만 안전하지 않은 HTTP 트래픽은 네트워크 공격자가 사이트의 보안 HTTPS 버전에서 사용될 쿠키를 조작할 수 있는 기회를 제공합니다. 스키마 간에 이 추가 교차 사이트 경계를 만들면 이러한 공격에 대한 방어력이 강화됩니다.

일반적인 교차 스키마 시나리오

이전에는 웹사이트의 교차 스키마 버전 간에 탐색 (예: http://site.example에서 https://site.example으로 연결)하면 SameSite=Strict 쿠키를 전송할 수 있었습니다. 이제 교차 사이트 탐색으로 처리되므로 SameSite=Strict 쿠키가 차단됩니다.

사이트의 안전하지 않은 HTTP 버전에서 안전한 HTTPS 버전으로 연결되는 링크를 따라 트리거되는 교차 스키마 탐색입니다. SameSite=Strict 쿠키가 차단되고 SameSite=Lax 및 SameSite=None; Secure 쿠키는 허용됩니다.
HTTP에서 HTTPS로의 교차 스키마 탐색
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 차단됨 ⛔ 차단됨
SameSite=Lax ✓ 허용됨 ✓ 허용됨
SameSite=None;Secure ✓ 허용됨 ⛔ 차단됨

하위 리소스 로드

여기서 변경하는 사항은 완전한 HTTPS로 업그레이드하는 동안의 임시 수정으로만 간주해야 합니다.

하위 리소스의 예로는 이미지, iframe, XHR 또는 Fetch로 만든 네트워크 요청이 있습니다.

이전에는 페이지에서 교차 스키마 하위 리소스를 로드하면 SameSite=Strict 또는 SameSite=Lax 쿠키를 전송하거나 설정할 수 있었습니다. 이제 다른 서드 파티 또는 교차 사이트 하위 리소스와 동일한 방식으로 처리되므로 SameSite=Strict 또는 SameSite=Lax 쿠키가 차단됩니다.

또한 브라우저에서 안전하지 않은 스키마의 리소스를 보안 페이지에 로드하도록 허용하더라도 이러한 요청에서 모든 쿠키가 차단됩니다. 서드 파티 또는 교차 사이트 쿠키에는 Secure가 필요하기 때문입니다.

사이트의 보안 HTTPS 버전의 리소스가 비보안 HTTP 버전에 포함되어 발생하는 교차 스키마 하위 리소스입니다. SameSite=Strict 및 SameSite=Lax 쿠키가 차단되고 SameSite=None; Secure 쿠키가 허용됩니다.
HTTPS를 통해 교차 스키마 하위 리소스를 포함하는 HTTP 페이지
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 차단됨 ⛔ 차단됨
SameSite=Lax ⛔ 차단됨 ⛔ 차단됨
SameSite=None;Secure ✓ 허용됨 ⛔ 차단됨

양식 POST

이전에는 웹사이트의 교차 스키마 버전 간에 게시하면 SameSite=Lax 또는 SameSite=Strict로 설정된 쿠키를 전송할 수 있었습니다. 이제 교차 사이트 POST로 처리되므로 SameSite=None 쿠키만 전송할 수 있습니다. 기본적으로 안전하지 않은 버전을 표시하지만 로그인 또는 결제 양식을 제출할 때 사용자를 보안 버전으로 업그레이드하는 사이트에서 이 시나리오가 발생할 수 있습니다.

하위 리소스와 마찬가지로 요청이 보안 컨텍스트 (예: HTTPS)에서 안전하지 않은 컨텍스트 (예: HTTP)로 전송되는 경우 이러한 요청에서 모든 쿠키가 차단됩니다. 서드 파티 또는 교차 사이트 쿠키에는 Secure가 필요하기 때문입니다.

사이트의 비보안 HTTP 버전의 양식이 보안 HTTPS 버전에 제출되어 발생하는 교차 스키마 양식 제출입니다. SameSite=Strict 및 SameSite=Lax 쿠키가 차단되고 SameSite=None; Secure 쿠키가 허용됩니다.
HTTP에서 HTTPS로의 교차 스키마 양식 제출
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 차단됨 ⛔ 차단됨
SameSite=Lax ⛔ 차단됨 ⛔ 차단됨
SameSite=None;Secure ✓ 허용됨 ⛔ 차단됨

사이트를 테스트하려면 어떻게 해야 하나요?

개발자 도구 및 메시지는 Chrome과 Firefox에서 사용할 수 있습니다.

Chrome 86부터 DevTools의 문제 탭에 스키마가 포함된 Same-Site 문제가 포함됩니다. 사이트에 대해 다음 문제가 강조표시될 수 있습니다.

탐색 문제:

  • '계속해서 쿠키가 동일 사이트 요청에서 전송되도록 하려면 HTTPS로 완전히 이전하세요' - 향후 Chrome 버전에서 쿠키가 차단될 것이라는 경고입니다.
  • '쿠키가 동일 사이트 요청에서 전송되도록 하려면 HTTPS로 완전히 이전하세요' - 쿠키가 차단되었음 을 알리는 경고입니다.

하위 리소스 로드 문제:

  • '계속해서 쿠키가 동일 사이트 하위 리소스로 전송되도록 하려면 HTTPS로 완전히 이전하세요' 또는 '계속해서 쿠키가 동일 사이트 하위 리소스에 의해 설정되도록 하려면 HTTPS로 완전히 이전하세요' - 향후 Chrome 버전에서 쿠키가 차단될 것이라는 경고입니다.
  • '쿠키가 동일 사이트 하위 리소스로 전송되도록 하려면 HTTPS로 완전히 이전하세요' 또는 '쿠키가 동일 사이트 하위 리소스에 의해 설정되도록 하려면 HTTPS로 완전히 이전하세요' - 쿠키가 차단되었음 을 알리는 경고입니다. 후자의 경고는 양식을 POST할 때도 표시될 수 있습니다.

자세한 내용은 스키마가 포함된 Same-Site의 테스트 및 디버깅 도움말을 참고하세요.

Firefox 79부터 about:config를 통해 network.cookie.sameSite.schemeful을 true로 설정하면 콘솔에 스키마가 포함된 Same-Site 문제에 관한 메시지가 표시됩니다. 사이트에 다음이 표시될 수 있습니다.

  • '스키마가 일치하지 않으므로 쿠키 cookie_name이 http://site.example/에 대해 교차 사이트 쿠키로 처리될 예정 입니다.'
  • '스키마가 일치하지 않으므로 쿠키 cookie_name이 http://site.example/에 대해 교차 사이트로 처리되었습니다.'

FAQ

사이트가 이미 HTTPS에서 완전히 제공되고 있는데 브라우저의 DevTools에 문제가 표시되는 이유는 무엇인가요?

일부 링크와 하위 리소스가 여전히 안전하지 않은 URL을 가리키고 있을 수 있습니다.

이 문제를 해결하는 한 가지 방법은 HTTP Strict-Transport-Security (HSTS) 및 includeSubDomain 디렉터리를 사용하는 것입니다. HSTS + includeSubDomain을 사용하면 페이지 중 하나에 안전하지 않은 링크가 실수로 포함되어 있더라도 브라우저에서 자동으로 보안 버전을 사용합니다.

HTTPS로 업그레이드할 수 없는 경우 어떻게 해야 하나요?

사용자를 보호하기 위해 사이트를 HTTPS로 완전히 업그레이드하는 것이 좋지만 직접 업그레이드할 수 없는 경우 호스팅 제공업체에 문의하여 해당 옵션을 제공할 수 있는지 확인하는 것이 좋습니다. 자체 호스팅하는 경우 Let's Encrypt에서 인증서를 설치하고 구성하는 데 사용할 수 있는 여러 도구를 제공합니다. HTTPS 연결을 제공할 수 있는 CDN 또는 기타 프록시 뒤로 사이트를 이동하는 것을 조사할 수도 있습니다.

그래도 불가능한 경우 영향을 받는 쿠키의 SameSite 보호를 완화해 보세요.

  • SameSite=Strict 쿠키만 차단되는 경우 보호를 Lax로 낮출 수 있습니다.
  • Strict 및 Lax 쿠키가 모두 차단되고 쿠키가 보안 URL로 전송되거나 보안 URL에서 설정되는 경우 보호를 None으로 낮출 수 있습니다.
    • 쿠키를 전송하거나 설정하는 URL이 안전하지 않은 경우 이 해결 방법은 실패 합니다. 이는 SameSite=None에 쿠키의 Secure 속성이 필요하기 때문입니다. 즉, 안전하지 않은 연결을 통해 이러한 쿠키를 전송하거나 설정할 수 없습니다. 이 경우 사이트가 HTTPS로 업그레이드될 때까지 해당 쿠키에 액세스할 수 없습니다.
    • 결국 서드 파티 쿠키가 완전히 단계적으로 중단되므로 이는 일시적인 해결 방법일 뿐입니다.

SameSite 속성을 지정하지 않은 경우 쿠키에 어떤 영향을 미치나요?

SameSite 속성이 없는 쿠키는 SameSite=Lax를 지정한 것처럼 처리되며 동일한 교차 스키마 동작이 이러한 쿠키에도 적용됩니다. 안전하지 않은 메서드에 대한 임시 예외는 여전히 적용됩니다. 자세한 내용은 Chromium SameSite FAQ의 Lax + POST 완화 를 참고하세요.

WebSocket은 어떤 영향을 받나요?

WebSocket 연결은 페이지와 동일한 보안 수준인 경우 동일 사이트로 간주됩니다.

동일 사이트:

  • https://의 wss:// 연결
  • http://의 ws:// 연결

교차 사이트:

  • http://의 wss:// 연결
  • https://의 ws:// 연결