flawopen.com/CSRF/SameSite 쿠키
SameSite=Strict가 CSRF 토큰을 대체하나요?
SameSite=Strict는 다른 사이트에서 시작된 쿠키 인증 요청을 막는 강력한 브라우저 보호 계층이지만 모든 CSRF를 막는 것은 아닙니다. 서로 다른 origin이어도 형제 하위 도메인은 같은 사이트로 취급될 수 있고, 속성을 적용하지 않는 클라이언트에는 보호가 없습니다. 위협 모델에 따라 CSRF 토큰이나 요청 출처 검증을 유지하세요.
SameSite의 실제 동작
SameSite=Strict 쿠키는 다른 사이트에서 온 요청에 포함되지 않으며, 다른 사이트가 폼을 자동 제출하는 전형적인 CSRF도 이에 해당합니다. 이 경우 브라우저가 세션 쿠키를 자동으로 붙이지 않습니다. SameSite는 origin이 아니라 site 기준입니다. 형제 하위 도메인의 요청도 same-site일 수 있으므로 Strict는 침해되었거나 신뢰할 수 없는 형제 호스트를 막지 못합니다. 외부 링크를 따라 사이트로 이동할 때 쿠키가 빠져 사용자가 인증되지 않은 상태로 도착할 수도 있습니다.
남아 있는 한계
애플리케이션이 bearer token을 Authorization 헤더에 명시적으로 넣는다면 SameSite는 해당 헤더를 제어하지 않습니다. 브라우저의 쿠키 자동 첨부와는 다른 동작입니다. 그렇다고 모든 설계가 안전한 것은 아닙니다. 다른 메커니즘이 자격 증명을 자동으로 첨부하는지 평가하고 토큰 탈취와 오용을 방지하세요.
명시적 SameSite=Lax는 same-site 요청과 GET 같은 안전한 메서드를 사용하는 cross-site 최상위 탐색에서 쿠키 전송을 허용하며, cross-site 하위 요청과 안전하지 않은 메서드의 탐색에서는 쿠키를 보내지 않습니다. 속성을 생략하면 사용자 에이전트의 기본값이 적용됩니다. Chromium에서는 이 기본 동작이 명시적 Lax와 다릅니다. 현재 구현은 명시적 속성이 없는 일부 쿠키를 생성 후 최대 2분 동안 안전하지 않은 cross-site 최상위 요청에 보낼 수 있습니다(Lax-allowing-unsafe). CSRF 방어에 이 브라우저별 호환 동작을 의존하지 마세요. 의도한 속성을 명시하고 지원 대상 클라이언트를 테스트하며 안전한 메서드로 상태 변경 작업을 수행할 수 없게 하세요.
SameSite는 브라우저가 적용합니다. 속성을 지원하거나 준수하지 않는 클라이언트는 보호받지 못합니다. 지원 클라이언트를 확인하고 SameSite를 적절한 CSRF 토큰, Origin 검증 등 기본 방어와 함께 심층 방어로 사용하세요.
자주 묻는 질문
안전한 메서드에 대한 별도 안내를 참조하세요. GET 같은 안전한 메서드로 상태 변경 작업에 접근할 수 없어야 합니다. 안전한 메서드는 서버 상태를 바꾸지 않는다는 전제가 있습니다.