---
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 트레이드오프).

## 관련

> 같은 주제의 다른 raw 자료, 또는 이 자료를 인용한 wiki 문서.

- `[[raw/official-docs/csrf-protection-spring-official]]` — Spring Security CSRF 방어(D1·D2 근거), 이 문서와 함께 D3~D4 완성
- `[[raw/official-docs/samesite-set-cookie-mdn-official]]` — 동일 D3 근거를 다루는 MDN `Set-Cookie` `SameSite` 레퍼런스(병행 dispatch로 archiving 완료 확인, 2026-07-25)
- `[[raw/official-docs/spring-boot-session-cookie-samesite-property-official]]` — `server.servlet.session.cookie.same-site` Spring Boot 프로퍼티 문서(병행 dispatch로 archiving 완료 확인, 2026-07-25)
- 같은 주제 미아카이빙 후보: OWASP CSRF Prevention Cheat Sheet
- 이 자료를 인용한 wiki 요약: (생성 시) `[[wiki/concepts/...]]`