llm-wiki/raw/official-docs/csrf-prevention-cheat-sheet-owasp-samesite-official.md

---
title: official-doc / OWASP Cross-Site Request Forgery Prevention Cheat Sheet — SameSite Defense-in-Depth
source_type: official-doc
url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
archive_url:
related_branches: [feature-keycloak-bff-csrf-samesite-defense]
related_projects: []
tags: [official-doc, keycloak-patterns, security, owasp, csrf, samesite]
created: 2026-07-25
---

# official-doc / OWASP Cross-Site Request Forgery Prevention Cheat Sheet — SameSite Defense-in-Depth

> Layer: `raw/official-docs/` — OWASP Cheat Sheet Series "Cross-Site Request Forgery Prevention Cheat Sheet" 페이지의 원문 발췌. `feature-keycloak-bff-csrf-samesite-defense` branch 의 D3(SameSite 를 CSRF token 의 **대체가 아닌 defense-in-depth 보완**으로 결합) 결정 근거로 보관. OWASP Cheat Sheet Series 는 특정 벤더 제품 문서가 아니라 산업 전반의 벤더 중립 공식 보안 레퍼런스이므로 `source_type: official-doc` (company-tech-blog 아님).

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-keycloak-bff-csrf-samesite-defense]] | D3 — SameSite 쿠키 속성을 CSRF token(D2, `csrf-protection-spring-official` 근거)의 **대체가 아닌 defense-in-depth 보완**으로 결합하는 프레이밍의 공식 근거. 세션 쿠키에 SameSite 적용 권고, Lax/Strict trade-off, synchronizer token 이 1차 방어라는 근거 포함 — 기존 `D3 UNSUPPORTED_DECISION` 라벨 해소용 |

## 출처

- 원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- 아카이브 URL: (미수집)
- 저자 / 조직: OWASP (Open Worldwide Application Security Project) Cheat Sheet Series — 벤더 중립 커뮤니티 보안 레퍼런스 (GitHub 기반 협업 편집, 다수 리뷰어)
- 발행일: 고정 발행일 없음 (rolling living document)
- 마지막 확인일: 2026-07-25

## 왜 저장했는지

branch 의 D3(SameSite 를 CSRF token 의 defense-in-depth 보완으로 결합)이 `UNSUPPORTED_DECISION` 상태였다 — 기존 유일한 근거(`csrf-protection-spring-official`)는 SameSite 를 전혀 언급하지 않기 때문. 이 문서는 SameSite 를 "does not replace a proper CSRF defense" 로 명시적으로 프레이밍하고, 세션 쿠키 적용 시 주의사항·Lax/Strict trade-off·synchronizer token 이 1차 방어라는 근거를 제공해 D3 를 뒷받침한다.

## 핵심 인용

> [§Limitations of SameSite] "SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments."

> [§Introduction] "SameSite Cookie Attribute can be used for session cookies but be careful to NOT set a cookie specifically for a domain."

> [§SameSite (Cookie Attribute)] "If a website wants to maintain a user's logged-in session after the user arrives from an external link, SameSite's default Lax value provides a reasonable balance between security and usability."

> [§Limitations of SameSite] "Top-level navigation and window-opening tricks. [...] SameSite=Strict blocks most of these at the cost of breaking legitimate cross-site links into the app."

> [§Token-Based Mitigation] "The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF."

## Claims Extracted (추출된 주장)

> `Claim ID` prefix: `OWASP-CSRF-SAMESITE`.

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OWASP-CSRF-SAMESITE-C1 | SameSite 는 defense-in-depth 통제이며 대부분의 배포 환경에서 적절한 CSRF 방어를 **대체하지 않는다** | [§Limitations of SameSite] "SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments." | `official-reference` | SameSite 단독 배포가 CSRF 방어로 충분한지 판단하는 일반 아키텍처 가이드 | 어떤 특정 프레임워크(Spring 등)의 실제 SameSite 기본값/런타임 동작을 증명하지 않음 — 이 branch 의 AP3 세션 쿠키가 실제로 어떤 SameSite 값을 갖는지는 별도 확인 필요 |
| OWASP-CSRF-SAMESITE-C2 | SameSite 쿠키 속성은 세션 쿠키에 적용 가능하나, 특정 도메인에 한정해서 설정하지 않도록 주의해야 한다(서브도메인 쿠키 공유 위험) | [§Introduction] "SameSite Cookie Attribute can be used for session cookies but be careful to NOT set a cookie specifically for a domain." | `official-reference` | SameSite 를 세션 쿠키(D3 가 적용 대상으로 고려하는 쿠키)에 적용하는 일반 권고 | 이 branch 의 실제 세션 쿠키 도메인 설정이 이 위험에 해당하는지는 이 문장만으로 증명되지 않음 — 프로젝트별 도메인 구성 확인 필요 |
| OWASP-CSRF-SAMESITE-C3 | 외부 링크를 통한 로그인 세션 유지가 필요한 경우, SameSite 의 기본값인 Lax 가 보안과 사용성 사이의 합리적 균형을 제공한다 | [§SameSite (Cookie Attribute)] "If a website wants to maintain a user's logged-in session after the user arrives from an external link, SameSite's default Lax value provides a reasonable balance between security and usability." | `official-reference` | Lax vs Strict 선택 기준 — 외부 링크 진입이 필요한 애플리케이션의 경우 Lax 선택 근거 | Lax 가 모든 CSRF 벡터를 차단한다는 것은 증명하지 않음(GET 기반 state-changing 우회 가능성은 이 문서의 별도 문단이 다룸, 이 claim 의 범위 밖) |
| OWASP-CSRF-SAMESITE-C4 | SameSite=Strict 는 top-level navigation/새 창 열기를 통한 공격 대부분을 차단하지만, 정상적인 cross-site 링크 진입을 깨뜨리는 비용(UX trade-off)이 있다 | [§Limitations of SameSite] "SameSite=Strict blocks most of these at the cost of breaking legitimate cross-site links into the app." | `official-reference` | Strict 채택 시 예상되는 UX 트레이드오프 근거 — 외부 링크 진입이 불필요한 애플리케이션에서 Strict 채택 근거 | 이 branch(AP3, keycloak IdP 리다이렉트 흐름 포함)가 외부 링크 진입에 의존하는지 여부는 이 문장이 판단하지 않음 — OIDC redirect flow 와 Strict 의 상호작용은 별도 검증 필요 |
| OWASP-CSRF-SAMESITE-C5 | synchronizer token pattern 은 CSRF 를 완화하는 가장 널리 쓰이고 권장되는 방법 중 하나다 | [§Token-Based Mitigation] "The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF." | `official-reference` | CSRF token(D2, 이미 `csrf-protection-spring-official` 로 별도 근거 확보)이 1차 방어이고 SameSite 는 그 보완이라는 D3 의 "combine, don't replace" 프레이밍 근거 | Spring Security 의 특정 구현(synchronizer token + `CookieCsrfTokenRepository`)이 이 일반 권고를 만족하는지는 이 문장 자체가 증명하지 않음 — 그 부분은 `csrf-protection-spring-official`(`SPRINGSEC-CSRF-C3`)이 별도로 증명 |

## Usage Boundaries (적용 경계)

- 이 자료가 직접 증명하는 것:
  - `OWASP-CSRF-SAMESITE-C1`: SameSite 는 defense-in-depth 이며 CSRF 방어의 대체가 아니라는 일반 원칙
  - `OWASP-CSRF-SAMESITE-C2`: 세션 쿠키에 SameSite 적용 시 서브도메인 공유 주의사항
  - `OWASP-CSRF-SAMESITE-C3`: Lax 가 외부 링크 진입 시나리오에서 보안·사용성 균형을 제공한다는 일반 권고
  - `OWASP-CSRF-SAMESITE-C4`: Strict 채택 시 예상되는 UX 트레이드오프
  - `OWASP-CSRF-SAMESITE-C5`: synchronizer token pattern 이 CSRF 완화의 대중적·권장 방법이라는 일반 진술
- 이 자료가 증명하지 않는 것:
  - Spring Security(D2) 의 실제 `CookieCsrfTokenRepository`/`XSRF-TOKEN` 쿠키가 어떤 SameSite 값을 기본으로 갖는지 — 이 문서는 벤더 중립 일반 가이드이며 Spring 구현 세부는 다루지 않음(`csrf-protection-spring-official` 범위)
  - AP3(BFF) 의 실제 세션 쿠키가 어떤 도메인/SameSite 조합으로 배포될지 — 코드 미구현(`NO_GROUND_TRUTH`)이라 이 문서만으로 확정 불가
  - Lax 냐 Strict 냐의 최종 선택 — 이 문서는 트레이드오프만 제시하며 이 branch 의 OIDC redirect 흐름(keycloak IdP 경유)과의 상호작용까지 판단하지 않음
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - AP3 세션 쿠키(`server.servlet.session.cookie.same-site`)와 `XSRF-TOKEN` 쿠키(`CookieCsrfTokenRepository`) 중 어느 쪽에 SameSite 를 적용할지 — branch §구현 가이드의 `UNSUPPORTED_IMPL_DECISION(a)` 로 남아 있으며 이 문서만으로 결정 불가(Applies to 범위 밖)
  - keycloak OIDC 로그인 리다이렉트가 top-level navigation 인지, 그 경로가 Strict 채택 시 깨지는지 실제 흐름으로 검증 필요

## 메모

> 검증되지 않은 내 해석. 사실 인용과 분리.

- D3 는 `OWASP-CSRF-SAMESITE-C1`+`C5` 조합("SameSite 는 보완이고 synchronizer token 이 1차 방어")으로 "combine, don't replace" 프레이밍이 뒷받침 가능해 보인다(미검증 — branch 갱신 시 재확인).
- SameSite 적용 대상(세션 쿠키 vs `XSRF-TOKEN` 쿠키)과 Lax vs Strict 값 선택은 이 문서가 원칙만 제공하고 detail 은 권고하지 않으므로, branch §구현 가이드의 `UNSUPPORTED_IMPL_DECISION` 라벨이 계속 유효하다(이 문서로 해소되는 것은 D3 의 "왜 결합하는가" 부분이지 "어디에 어떤 값으로" 부분이 아님).
- 추가로 봐야 할 동일 출처 페이지: 같은 페이지의 "Using Standard Headers to Verify Origin" 섹션(Origin/Referer 검증), Spring Session reference 의 쿠키 직렬화 옵션 페이지(SameSite 적용 대상 detail 확정 시 필요).

## 관련

- 같은 주제 다른 official-doc: [[raw/official-docs/csrf-protection-spring-official]] — Spring Security 의 실제 CSRF token 구현 메커니즘(D2) 근거. 이 문서(OWASP)는 SameSite 프레이밍(D3) 보완이며 서로 겹치지 않는 근거 제공
- 이 자료를 인용한 wiki 요약: `[[wiki/concepts/...]]` (생성 시)