title: official-doc / IETF Internet-Draft — draft-ietf-httpbis-rfc6265bis (Cookies: HTTP State Management Mechanism) §SameSite Attribute source_type: official-doc url: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ archive_url: related_branches: [feature-keycloak-bff-csrf-samesite-defense] related_projects: [keycloak-patterns-overview] tags: [official-doc, keycloak-patterns, security, ietf, samesite, csrf] created: 2026-07-25

official-doc / IETF Internet-Draft — draft-ietf-httpbis-rfc6265bis §SameSite Attribute

Layer: raw/ — 외부 자료(공식 문서 / 대기업 기술 블로그)의 원문 발췌·출처 기록. 본 템플릿은 raw/official-docs/ 와 raw/company-tech-blogs/ 두 폴더가 공유. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

⚠️ 문서 상태 (CRITICAL — 확정 RFC 아님)

이 자료는 2026-07 기준 여전히 IETF Internet-Draft(초안) 이다 — draft-ietf-httpbis-rfc6265bis, 확정 RFC 번호 미부여. RFC 6265를 대체(obsolete)할 예정인 후속 문서이며, 인용 시점(2026-07-25)에 확인한 버전은 draft-ietf-httpbis-rfc6265bis-22, 발행일 1 December 2025, Intended Status: Standards Track, Expires: 4 June 2026, datatracker 상 "Active Internet-Draft (httpbis WG)" 상태다. 최종 RFC Editor 편집 과정에서 문구가 바뀔 수 있으므로 "IETF Internet-Draft(RFC 6265 대체 예정, 미확정)"으로만 취급하고, "확정된 RFC" 처럼 서술하지 않는다. source_type: official-doc 으로 아카이빙하되 — official-doc ≠ 확정 표준 완료. Strength 는 아래 Claims 표에서 official-standard 로 표기하지만, 이는 "IETF 표준 트랙 프로세스 산출물"이라는 뜻이지 "이미 확정된 RFC"라는 뜻이 아님을 매 사용처에서 구분해야 한다.

활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
`[[raw/branch-notes/feature-keycloak-bff-csrf-samesite-defense]]`	D3 — SameSite 세 값(Strict/Lax/None)의 표준 정의, 특히 `Lax` 가 cross-site top-level navigation(safe method)에 쿠키를 허용하도록 정의됨을 근거로 AP3 BFF 외부 IdP 로그인 흐름에서 `SameSite=Lax` 를 선택하는 것을 정당화(MDN 서술의 primary-source 근거)

출처

원본 URL: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ (latest 버전으로 자동 리다이렉트)
인용 시점 실제 확인 버전: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-22
아카이브 URL: (2026-07-25 확인 시점 web.archive.org 기존 스냅샷 없음 — Wayback Availability API 조회 결과 archived_snapshots: {})
저자 / 조직: Steven Bingler (editor, Google/Chromium), Mike West (editor, Google LLC), John Wilander (editor, Apple, Inc)
발행일: 1 December 2025 (draft -22)
문서 제목: "Cookies: HTTP State Management Mechanism" (RFC 6265 obsoletes 예정)
마지막 확인일: 2026-07-25

왜 저장했는지

feature-keycloak-bff-csrf-samesite-defense 브랜치의 D3(UNSUPPORTED_DECISION — SameSite 를 CSRF defense-in-depth 로 결합)가 "SameSite 근거 소스 미확보" 상태였다. 이 IETF 초안은 SameSite 세 값의 표준 정의 원문이며, 특히 Lax 가 cross-site top-level navigation(safe method, 예: 외부 IdP 로그인 후 302 리다이렉트)에서 쿠키를 허용하도록 명시한 문장이 D3의 핵심 근거(crux)다. 동시에 이 문서는 Lax 가 cross-site top-level POST 콜백에는 부적합함을 명시적으로 경고하므로, D3 확정 전 AP3 로그인 콜백이 GET인지 POST인지 반드시 확인해야 한다는 경계도 함께 제공한다.

핵심 인용

원문 그대로. 따옴표·줄바꿈 보존. 페이지·섹션 번호 있으면 같이.

[§4.1.2.7 The SameSite Attribute] "If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests."

[§4.1.2.7 The SameSite Attribute] "If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in Section 5.6.7.1."

[§4.1.2.7 The SameSite Attribute] "If the value is "None", the cookie will be sent with same-site and cross-site requests."

[§5.6.7.1 "Strict" and "Lax" enforcement] "Same-site cookies in "Strict" enforcement mode will not be sent along with top-level navigations which are triggered from a cross-site document context. [...] In the interests of providing a drop-in mechanism that mitigates the risk of CSRF attacks, developers may set the SameSite attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a "safe" (in the [HTTP] sense) HTTP method."

[§8.8.6 Top-level requests with "unsafe" methods] "For example, the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow."

Claims Extracted

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

Claim ID	Claim	Evidence quote	Strength	Applies to	Does not prove
RFC6265BIS-SAMESITE-C1	`Strict` 값은 same-site 요청에만 쿠키를 전송하고, cross-site document context 에서 트리거된 top-level navigation 에는 전송하지 않는다	[§4.1.2.7] "the cookie will only be sent along with "same-site" requests" / [§5.6.7.1] "will not be sent along with top-level navigations which are triggered from a cross-site document context"	`official-standard`	SameSite=Strict 로 설정된 쿠키의 표준 정의된 전송 범위	아직 확정 RFC 번호 미부여(Internet-Draft) — 문구가 RFC Editor 단계에서 바뀔 수 있음. 특정 브라우저의 실제 구현 conformance 를 증명하지 않음
RFC6265BIS-SAMESITE-C2	`Lax` 값은 same-site 요청뿐 아니라, safe(HTTP 의미의) method 를 사용하는 top-level navigation 인 cross-site 요청에도 쿠키를 전송한다 (crux for D3)	[§4.1.2.7] "the cookie will be sent with same-site requests, and with "cross-site" top-level navigations" / [§5.6.7.1] "carves out an exception which sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a "safe" ... HTTP method"	`official-standard`	외부 IdP 로그인 후 GET 기반 302 top-level 리다이렉트로 앱에 돌아오는 시나리오에 SameSite=Lax 쿠키가 전송됨	POST 기반 로그인 콜백(예: `response_mode=form_post`)에도 전송된다는 것은 증명하지 않음(C5 참조, 오히려 반대를 명시). Spring Security/서블릿 컨테이너의 실제 쿠키 설정 기본값을 증명하지 않음
RFC6265BIS-SAMESITE-C3	`None` 값은 same-site 및 cross-site 요청 모두에 쿠키를 전송한다	[§4.1.2.7] "the cookie will be sent with same-site and cross-site requests"	`official-standard`	SameSite 미적용(구 동작)과 동등한 명시적 opt-in 값	이 인용만으로는 `None` 이 `Secure` 속성과 병행 요구되는지 여부는 증명하지 않음(별도 섹션, 본 노트 미인용)
RFC6265BIS-SAMESITE-C4	`Lax` 모드는 CSRF 위험을 완화하면서도 정당한 cross-site top-level navigation(safe method)을 깨지 않기 위한 "drop-in mechanism"으로 설계되었다 — `Lax` 를 선택하는 이유(rationale)	[§5.6.7.1] "In the interests of providing a drop-in mechanism that mitigates the risk of CSRF attacks, developers may set the SameSite attribute in a "Lax" enforcement mode..."	`official-standard`	D3 의 "왜 Strict 대신 Lax 인가" 질문에 대한 표준 근거 — AP3 외부 IdP 리다이렉트가 GET/safe-method top-level navigation 인 경우에 한해 적용	AP3 의 실제 리다이렉트가 GET 인지는 코드/설정 확인 필요(이 문서는 메커니즘만 진술, 우리 프로젝트의 실제 흐름 형태를 증명하지 않음). 같은 문단이 이어서 "Lax enforcement ... does not offer a robust defense against CSRF as a general category of attack"이라 명시 — Lax 단독이 아니라 CSRF token(D2)과 병행이 전제
RFC6265BIS-SAMESITE-C5	`Lax` 는 cross-site top-level POST 요청으로 완료되는 로그인 콜백에는 부적합하다 — 그런 쿠키에 Lax 를 적용하면 unsafe method 때문에 쿠키가 제외되어 로그인 흐름 전체가 복구 불가능하게 실패할 수 있다 (중요 경계)	[§8.8.6] "For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow."	`official-standard`	OIDC `response_mode=form_post` 등 POST 기반 콜백을 쓰는 로그인 흐름 일반에 대한 경고	AP3(keycloak-patterns-overview)의 외부 IdP 콜백이 실제로 GET 인지 POST 인지는 이 문서가 증명하지 않음 — D3 확정 전 반드시 확인 필요. "Lax-allowing-unsafe"(문서가 제안하는 호환성 완화 모드)가 우리 상황에 적합한지도 이 인용만으로는 증명하지 않음(2분 쿠키 나이 제한 등 별도 트레이드오프 미검토)

Strength 허용값

official-standard — RFC, 표준 사양, 언어/프로토콜 표준
official-vendor-doc — Spring, Keycloak, AWS, Google 등 공식 벤더 문서
official-reference — 공식 reference/API 문서
company-case-study — 대기업/실무 기술 블로그의 특정 사례
engineering-blog — 개인/팀 블로그의 엔지니어링 해설
tutorial — 튜토리얼/가이드. 일반화 금지
needs-confirmation — 원문만으로는 적용 판단 불가

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- C1~C3: SameSite 세 값(Strict/Lax/None)의 표준 정의된 쿠키 전송 범위
- C4: Lax 가 존재하는 이유(top-level navigation 호환성 유지 + CSRF 완화)
- C5: Lax 가 cross-site top-level POST 콜백에는 부적합하다는 명시적 경계
이 자료가 증명하지 않는 것:
- 아직 확정 RFC 가 아니므로 "최종 표준 문구"임을 증명하지 않음 — RFC Editor 단계에서 편집될 수 있음
- 특정 브라우저(Chrome/Safari/Firefox)가 이 초안 문구를 byte-for-byte 준수해 구현했다는 것을 증명하지 않음(브라우저는 이전 draft/실무 관행 기반으로 이미 SameSite 를 구현 중)
- Spring Security 의 server.servlet.session.cookie.same-site 또는 CookieCsrfTokenRepository 의 실제 기본값/설정 동작을 증명하지 않음 (그건 [[raw/official-docs/csrf-protection-spring-official]] 의 범위)
- AP3(keycloak-patterns-overview)의 외부 IdP 로그인 콜백이 GET 인지 POST 인지를 증명하지 않음 — 이건 프로젝트 코드/OIDC 클라이언트 설정 확인 사항
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- AP3 BFF 의 외부 IdP 리다이렉트 콜백이 top-level GET navigation 인지 (OIDC response_mode 값 확인) — GET 이면 C2/C4 로 SameSite=Lax 정당화, POST 이면 C5 경고가 적용되어 Lax 단독으로는 부적합
- SESSION 쿠키와 XSRF-TOKEN 쿠키 중 어디에 SameSite 를 적용할지 (이 문서는 일반 SameSite 속성만 다루며, Spring 의 두 쿠키 각각의 설정 방법은 별도 확인 필요 — csrf-protection-spring-official 과 교차 확인)

메모

나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것 (그것은 wiki/concepts의 source-summary 또는 wiki/projects 본문에서만 작성).

인용 1 해석 후보 (미검증): AP3 콜백이 GET 302 리다이렉트라면 D3 는 C2/C4 로 UNSUPPORTED_DECISION 에서 지지된 결정으로 승급 가능해 보임 — 단, 코드 미구현 상태라 실제 검증 전까지는 추정일 뿐.
추가로 봐야 할 동일 출처 페이지: 같은 문서의 §5.7(쿠키 생성 시 top-level navigation 규칙), §4.1.2.8(Secure 속성과 None 의 관계 — 이 노트에서 미인용), §8.8.2(Top-level Navigations 상세, 세션 쿠키 UX 트레이드오프).

13 KiB Raw Blame History