쿠키: HTTP 상태 관리 메커니즘

2.1. 적합성 기준

이 문서에서 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL"은 여기 표시된 것처럼 모두 대문자로 나타날 때, 그리고 오직 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석된다.¶

알고리즘의 일부로 명령형으로 표현된 요구사항(예: "strip any leading space characters" 또는 "return false and abort this algorithm")은 해당 알고리즘을 도입할 때 사용된 핵심 단어("MUST", "SHOULD", "MAY" 등)의 의미로 해석된다.¶

알고리즘이나 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등하다면 어떤 방식으로든 구현할 수 있다. 특히 이 명세에서 정의하는 알고리즘은 이해하기 쉽도록 의도된 것이며, 성능이 뛰어나도록 의도된 것은 아니다.¶

2.2. 구문 표기법

이 명세는 [RFC5234]의 Augmented Backus-Naur Form(ABNF) 표기법을 사용한다.¶

다음 핵심 규칙은 [RFC5234] 부록 B.1에 정의된 대로 참조로 포함된다: ALPHA(문자), CR(캐리지 리턴), CRLF(CR LF), CTLs (제어 문자), DIGIT(10진수 0-9), DQUOTE(큰따옴표), HEXDIG (16진수 0-9/A-F/a-f), LF(라인 피드), NUL(null 옥텟), OCTET(NUL을 제외한 임의의 8비트 데이터 시퀀스), SP(공백), HTAB(수평 탭), CHAR(임의의 [USASCII] 문자), VCHAR(임의의 표시 가능한 [USASCII] 문자), WSP(공백류).¶

OWS(선택적 공백)와 BWS(잘못된 공백) 규칙은 [HTTP]의 5.6.3절에 정의되어 있다.¶

2.3. 용어

"user agent", "client", "server", "proxy", "origin server"라는 용어는 HTTP/1.1 명세([HTTP]의 3절)에서와 같은 의미를 가진다.¶

request-host는 사용자 에이전트가 알고 있는 호스트의 이름으로, 사용자 에이전트가 HTTP 요청을 보내고 있거나 HTTP 응답을 받고 있는 호스트 (즉, 대응하는 HTTP 요청을 보낸 호스트의 이름)를 말한다.¶

request-uri라는 용어는 [HTTP]의 7.1절에 정의된 "target URI"를 가리킨다.¶

두 옥텟 시퀀스가 대소문자를 구분하지 않고 서로 일치한다고 하는 것은 [RFC4790]에 정의된 i;ascii-casemap 정렬 기준 아래에서 두 시퀀스가 동등한 경우, 그리고 오직 그 경우뿐이다.¶

string이라는 용어는 NUL이 아닌 옥텟의 시퀀스를 의미한다.¶

"active browsing context", "active document", "ancestor navigables", "container document", "content navigable", "dedicated worker", "Document", "inclusive ancestor navigables", "navigable", "navigate", "opaque origin", "sandboxed origin browsing context flag", "shared worker", "the worker's Documents", "top-level traversable", "WorkerGlobalScope"라는 용어는 [HTML]에 정의되어 있다.¶

"Service Workers"는 Service Workers 명세 [SERVICE-WORKERS]에 정의되어 있다.¶

"origin"이라는 용어, URI에서 origin을 도출하는 메커니즘, 그리고 origin에 대한 "the same" 일치 알고리즘은 [RFC6454]에 정의되어 있다.¶

"안전한" HTTP 메서드에는 [HTTP]의 9.2.1절에 정의된 GET, HEAD, OPTIONS, TRACE가 포함된다.¶

도메인의 "public suffix"는 "com", "co.uk", "pvt.k12.wy.us"와 같이 공개 레지스트리가 제어하는 도메인의 부분이다. 도메인의 "registrable domain"은 도메인의 public suffix와 그 왼쪽의 레이블을 합친 것이다. 즉, https://www.site.example의 경우 public suffix는 example이고, registrable domain은 site.example이다. 보안 고려사항은 8.9절을 참조하라.¶

"request"라는 용어와 요청의 "client", "current url", "method", "target browsing context", "url list"는 [FETCH]에 정의되어 있다.¶

"non-HTTP APIs"라는 용어는 쿠키를 설정하고 검색하는 데 사용되는 비HTTP 메커니즘, 예를 들어 스크립트에 쿠키를 노출하는 웹 브라우저 API를 가리킨다.¶

"top-level navigation"이라는 용어는 top-level traversable의 탐색을 가리킨다.¶

2.4. 이름 확인 시스템

이 문서는 쿠키와 함께 사용할 특정 이름 확인 시스템을 엄격히 규정하지는 않지만, 해당 시스템이 [USASCII] 문자만 사용하거나 ASCII 호환 인코딩(ACE)을 사용할 것을 요구한다. Domain Name System(DNS)이 전형적이고 관례적인 예이므로, 이 문서는 이름 확인을 DNS 관점에서 참조할 것이다.¶

Unicode와 같이 비ASCII 문자를 직접 노출하는 이름 확인 시스템은 이 문서의 범위를 벗어난다.¶

3.1. 예시

Set-Cookie 헤더 필드를 사용하여 서버는 HTTP 응답에서 사용자 에이전트에 짧은 문자열을 보낼 수 있으며, 사용자 에이전트는 쿠키의 범위 안에 있는 향후 HTTP 요청에서 그 문자열을 반환한다. 예를 들어, 서버는 사용자 에이전트에 31d4d96e407aad42 값을 가진 SID라는 "session identifier"를 보낼 수 있다. 그러면 사용자 에이전트는 후속 요청에서 그 세션 식별자를 반환한다.¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

서버는 Path 및 Domain 속성을 사용하여 쿠키의 기본 범위를 변경할 수 있다. 예를 들어, 서버는 사용자 에이전트에 site.example의 모든 경로와 모든 하위 도메인에 쿠키를 반환하도록 지시할 수 있다.¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

다음 예시에서 보듯이, 서버는 사용자 에이전트에 여러 쿠키를 저장할 수 있다. 예를 들어, 서버는 두 개의 Set-Cookie 헤더 필드를 반환하여 세션 식별자와 사용자의 선호 언어를 저장할 수 있다. 더 민감한 세션 식별자에 추가 보안 보호를 제공하기 위해 서버가 Secure 및 HttpOnly 속성을 사용한다는 점에 유의하라 (4.1.2절 참조).¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=site.example

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

위 Cookie 헤더 필드에는 SID라는 이름의 쿠키 하나와 lang이라는 이름의 쿠키 하나, 총 두 개의 쿠키가 포함되어 있다는 점에 유의하라.¶

쿠키 이름은 대소문자를 구분한다. 즉, 서버가 이름의 대소문자만 다른 두 개의 Set-Cookie 헤더 필드를 사용자 에이전트에 보내면, 사용자 에이전트는 후속 요청에서 이 두 쿠키를 모두 저장하고 반환한다.¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42
Set-Cookie: sid=31d4d96e407aad42

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42

서버가 사용자 에이전트가 여러 "세션"(예: 사용자 에이전트 재시작)에 걸쳐 쿠키를 지속하기를 원한다면, 서버는 Expires 속성에 만료 날짜를 지정할 수 있다. 사용자 에이전트의 쿠키 저장소가 할당량을 초과하거나 사용자가 서버의 쿠키를 수동으로 삭제하는 경우, 사용자 에이전트가 만료 날짜 전에 쿠키를 삭제할 수 있음에 유의하라.¶

== Server -> User Agent ==

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2026 10:18:14 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

마지막으로 쿠키를 제거하려면, 서버는 과거의 만료 날짜를 가진 Set-Cookie 헤더 필드를 반환한다. 서버는 Set-Cookie 헤더 필드의 Path 및 Domain 속성이 쿠키가 생성될 때 사용된 값과 일치하는 경우에만 쿠키 제거에 성공한다.¶

== Server -> User Agent ==

Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

3.2. 구현할 요구사항 선택

이어지는 두 절인 4절과 5절은 두 가지 서로 다른 구현 유형에 대한 요구사항 집합을 논의한다. 이 절은 구현자가 자신의 목표에 가장 적합한 요구사항 집합을 판단하는 데 도움을 주기 위한 것이다. 잘못된 요구사항 집합을 선택하면 다른 쿠키 구현과의 호환성이 부족해질 수 있다.¶

호환성이 있다는 것이 구현자의 목표에 따라 서로 다른 의미를 가진다는 점이 중요하다. 이러한 차이는 의도적·비의도적 명세 변경, 명세 해석, 역사적 구현 차이로 인해 시간이 지나며 축적되어 왔다.¶

이 절은 쿠키 명세의 구현자를 대략 두 유형, 즉 생산자와 소비자로 나눈다. 이는 공식 용어가 아니며, 독자가 사용 사례를 직관적으로 이해하도록 돕기 위해 여기에서만 사용된다.¶

4.1. Set-Cookie 헤더

Set-Cookie HTTP 응답 헤더 필드는 서버에서 사용자 에이전트로 쿠키를 보내는 데 사용된다.¶

set-cookie        = set-cookie-string
set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
cookie-pair       = cookie-name BWS "=" BWS cookie-value
cookie-name       = token
cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                      ; US-ASCII characters excluding CTLs,
                      ; whitespace, DQUOTE, comma, semicolon,
                      ; and backslash
token             = <token, defined in [HTTP], Section 5.6.2>

cookie-av         = expires-av / max-age-av / domain-av /
                    path-av / secure-av / httponly-av /
                    samesite-av / extension-av
expires-av        = "Expires" BWS "=" BWS sane-cookie-date
sane-cookie-date  =
    <IMF-fixdate, defined in [HTTP], Section 5.6.7>
max-age-av        = "Max-Age" BWS "=" BWS 1*DIGIT
domain-av         = "Domain" BWS "=" BWS domain-value
domain-value      = <subdomain>
                      ; see details below
path-av           = "Path" BWS "=" BWS path-value
path-value        = *av-octet
secure-av         = "Secure"
httponly-av       = "HttpOnly"
samesite-av       = "SameSite" BWS "=" BWS samesite-value
samesite-value    = "Strict" / "Lax" / "None"
extension-av      = 1*av-octet
av-octet          = %x20-3A / %x3C-7E
                      ; any CHAR except CTLs or ";"

Set-Cookie: __Secure-SID=12345; Domain=site.example

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

Set-Cookie: __Host-SID=12345
Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

Set-Cookie: __Host-SID=12345; Secure; Path=/

4.2. Cookie 헤더

cookie        = cookie-string
cookie-string = cookie-pair *( ";" SP cookie-pair )

5.1. 하위 구성요소 알고리즘

이 절은 사용자 에이전트가 Cookie 및 Set-Cookie 헤더 필드의 특정 하위 구성요소를 처리하는 데 사용하는 몇 가지 알고리즘을 정의한다.¶

5.2. "Same-site" 및 "cross-site" 요청

두 origin이 [SAMESITE]에 정의된 "same site" 기준을 만족하면 same-site이다. 다음 기준이 참이면 요청은 "same-site"이다:¶

1. 요청이 사용자 인터페이스 요소를 통해 트리거된 새로고침 탐색의 결과가 아니다(사용자 에이전트가 정의한 대로; 예: 사용자가 툴바의 새로고침 버튼을 클릭해 트리거한 요청).¶

2. 요청의 current url의 origin이 요청 클라이언트의 "site for cookies"(origin임)와 same-site이거나, 요청에 클라이언트가 없거나 요청의 클라이언트가 null이다.¶

사용자 인터페이스 요소를 통해 트리거된 새로고침 탐색의 결과인 요청은, 다시 로드된 문서가 원래 same-site 요청을 통해 탐색된 경우 same-site이다. "same-site"가 아닌 요청은 대신 "cross-site"이다.¶

요청 클라이언트의 "site for cookies"는 다음 하위 절에 설명된 대로 클라이언트 유형에 따라 계산된다:¶

5.3. Set-Cookie 헤더 필드 무시

사용자 에이전트는 100 레벨 상태 코드가 있는 응답에 포함된 Set-Cookie 헤더 필드를 무시하거나, 자신의 쿠키 정책에 따라 무시할 수 있다(MAY)(7.2절 참조).¶

그 밖의 모든 Set-Cookie 헤더 필드는 5.6절에 따라 처리하는 것이 좋다(SHOULD). 즉, 100 레벨이 아닌 상태 코드가 있는 응답(400 및 500 레벨 상태 코드의 응답도 포함)에 포함된 Set-Cookie 헤더 필드는 사용자 에이전트의 쿠키 정책에 따라 무시되지 않는 한 처리하는 것이 좋다(SHOULD).¶

5.4. 쿠키 이름 접두사

쿠키 이름 접두사에 대한 사용자 에이전트의 요구사항은 서버의 요구사항(4.1.3절)과 약간 다르다. UA는 접두사 문자열을 대소문자를 구분하지 않고 일치시켜야 하기 때문이다(MUST).¶

접두사에 대한 규범 요구사항은 5.7절에 정의된 저장 모델 알고리즘에 자세히 설명되어 있다.¶

이는 일부 서버가 쿠키를 대소문자를 구분하지 않고 처리하여, 의도치 않게 대소문자가 잘못된 접두사를 잘못 대문자화하고 수락하는 결과를 낳기 때문이다.¶

예를 들어, 서버가 다음 Set-Cookie 헤더 필드를 보낸다면¶

Set-Cookie: __SECURE-SID=12345

접두사를 대소문자를 구분하여 검사하는 UA는 이 쿠키를 수락하며, 서버는 그 쿠키가 __Secure-로 철자된 쿠키와 동일한 보장의 대상이라고 잘못 믿게 된다.¶

또한 서버는 공격자가 접두사가 붙은 쿠키를 가장하기 위해 의도적으로 쿠키의 대소문자를 잘못 쓰는 공격에 취약하다. 예를 들어, 사이트에 이미 __Secure-SID=12345 쿠키가 있고, 어떤 수단으로든 공격자가 접두사를 대소문자를 구분하여 검사하는 UA에 대해 해당 사이트에 다음 Set-Cookie 헤더 필드를 보낸다고 하자.¶

Set-Cookie: __SeCuRe-SID=evil

다음에 사용자가 사이트를 방문하면 UA는 두 쿠키를 모두 보낸다:¶

Cookie: __Secure-SID=12345; __SeCuRe-SID=evil

대소문자를 구분하지 않는 서버는 두 쿠키를 구분할 수 없으므로, 공격자가 사이트를 침해할 수 있게 된다.¶

이러한 문제를 방지하기 위해 UA는 쿠키 이름 접두사를 대소문자를 구분하지 않고 일치시켜야 한다(MUST).¶

참고: 이름이 다른 쿠키는 여전히 UA에 의해 별개의 것으로 간주된다. 따라서 __Secure-foo=bar와 __secure-foo=baz는 서로 다른 쿠키로 동시에 존재할 수 있으며, 둘 다 __Secure- 접두사의 요구사항이 적용된다.¶

다음은 적합한 사용자 에이전트가 거부할 Set-Cookie 헤더 필드의 예이다.¶

Set-Cookie: __Secure-SID=12345; Domain=site.example
Set-Cookie: __secure-SID=12345; Domain=site.example
Set-Cookie: __SECURE-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345
Set-Cookie: __host-SID=12345; Secure
Set-Cookie: __host-SID=12345; Domain=site.example
Set-Cookie: __HOST-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Domain=site.example; Path=/

반면 다음 Set-Cookie 헤더 필드는 보안 origin에서 설정된 경우 수락된다.¶

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure
Set-Cookie: __Host-SID=12345; Secure; Path=/
Set-Cookie: __host-SID=12345; Secure; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Path=/

5.5. 쿠키 수명 제한

Expires 속성 또는 Max-Age 속성으로 지정된 수명을 가진 쿠키를 처리할 때, 사용자 에이전트는 쿠키의 최대 나이를 제한해야 한다(MUST). 그 제한은 미래 400일(34560000초)보다 크지 않은 것이 좋다(SHOULD NOT). 권장 제한은 미래 400일이지만, 사용자 에이전트는 그 제한을 조정할 수 있다(MAY) (7.2절 참조). 제한보다 긴 수명을 지정하는 Expires 또는 Max-Age 속성은 그 제한으로 줄여야 한다(MUST).¶

5.6. Set-Cookie 헤더 필드

사용자 에이전트가 HTTP 응답에서 Set-Cookie 헤더 필드를 받으면, 사용자 에이전트는 Set-Cookie 헤더 필드 전체를 무시할 수 있다(MAY) (5.3절 참조).¶

사용자 에이전트가 Set-Cookie 헤더 필드 전체를 무시하지 않는 경우, 사용자 에이전트는 Set-Cookie 헤더 필드의 field-value를 set-cookie-string(아래에 정의됨)으로 파싱해야 한다(MUST).¶

참고: 아래 알고리즘은 4.1절의 문법보다 더 관대하다. 예를 들어, 이 알고리즘은 cookie-name이 4.1절에 지정된 token이 아니라 cookie-octets로 구성될 수 있도록 허용하며, 4.1절의 문법에 따르면 cookie-octets가 아닌 일부 문자도 수용한다. 또한 아래 알고리즘은 쿠키 이름과 값에서 앞뒤 공백을 제거하지만(내부 공백은 유지), 4.1절의 문법은 이러한 위치의 공백을 금지한다. 사용자 에이전트는 4절의 권장사항을 따르지 않는 서버와 상호운용하기 위해 이 알고리즘을 사용한다.¶

참고: set-cookie-string은 비HTTP API에서 올 수 있으므로 CTL 문자가 없다고 보장할 수 없다. 따라서 이 알고리즘은 이를 명시적으로 처리한다. 수평 탭(%x09)은 set-cookie-string 거부로 이어지는 CTL 문자에서 제외되는데, 이는 공백으로 간주되어 별도로 처리되기 때문이다.¶

참고: set-cookie-string은 [RFC3986]의 2.1절에 따른 percent-encoded처럼 보이는 옥텟 시퀀스를 포함할 수 있다. 그러나 사용자 에이전트는 이러한 시퀀스를 디코딩해서는 안 되며(MUST NOT), 대신 이 알고리즘에 지정된 대로 개별 옥텟을 파싱해야 한다.¶

사용자 에이전트는 set-cookie-string을 파싱하기 위해 다음 알고리즘과 동등한 알고리즘을 사용해야 한다(MUST):¶

1. set-cookie-string이 %x00-08 / %x0A-1F / %x7F 문자 (HTAB을 제외한 CTL 문자)를 포함하면: 이 알고리즘을 중단하고 set-cookie-string 전체를 무시한다.¶

2. set-cookie-string이 %x3B(";") 문자를 포함하면:¶

   1. name-value-pair 문자열은 첫 번째 %x3B(";") 문자를 포함하지 않고 그 전까지의 문자로 구성되며, unparsed-attributes는 문제의 %x3B(";")를 포함한 set-cookie-string의 나머지로 구성된다.¶

   그렇지 않으면:¶

   1. name-value-pair 문자열은 set-cookie-string에 포함된 모든 문자로 구성되며, unparsed-attributes는 빈 문자열이다.¶

3. name-value-pair 문자열에 %x3D("=") 문자가 없으면, name 문자열은 비어 있고 value 문자열은 name-value-pair의 값이다.¶

   그렇지 않으면 (비어 있을 수 있는) name 문자열은 첫 번째 %x3D("=") 문자를 포함하지 않고 그 전까지의 문자로 구성되며, (비어 있을 수 있는) value 문자열은 첫 번째 %x3D("=") 문자 뒤의 문자로 구성된다.¶

4. name 문자열과 value 문자열에서 앞뒤 WSP 문자를 제거한다.¶

5. name 문자열과 value 문자열 길이의 합이 4096 옥텟보다 크면, 이 알고리즘을 중단하고 set-cookie-string 전체를 무시한다.¶

6. cookie-name은 name 문자열이고, cookie-value는 value 문자열이다.¶

사용자 에이전트는 unparsed-attributes를 파싱하기 위해 다음 알고리즘과 동등한 알고리즘을 사용해야 한다(MUST):¶

1. unparsed-attributes 문자열이 비어 있으면, 이 단계들의 나머지를 건너뛴다.¶

2. unparsed-attributes의 첫 문자를 버린다(그 문자는 %x3B(";") 문자일 것이다).¶

3. 남은 unparsed-attributes가 %x3B(";") 문자를 포함하면:¶

   1. unparsed-attributes의 문자를 첫 번째 %x3B(";") 문자 전까지 소비하되, 그 문자는 포함하지 않는다.¶

   그렇지 않으면:¶

   1. unparsed-attributes의 나머지를 소비한다.¶

   cookie-av 문자열을 이 단계에서 소비된 문자들로 둔다; 이제 unparsed-attributes는 남아 있는 문자를 포함한다.¶

4. cookie-av 문자열이 %x3D("=") 문자를 포함하면:¶

   1. (비어 있을 수 있는) attribute-name 문자열은 첫 번째 %x3D("=") 문자를 포함하지 않고 그 전까지의 문자로 구성되며, (비어 있을 수 있는) attribute-value 문자열은 첫 번째 %x3D("=") 문자 뒤의 문자로 구성된다.¶

   그렇지 않으면:¶

   1. attribute-name 문자열은 전체 cookie-av 문자열로 구성되며, attribute-value 문자열은 비어 있다.¶

5. attribute-name 문자열과 attribute-value 문자열에서 앞뒤 WSP 문자를 제거한다.¶

6. attribute-value가 1024 옥텟보다 길면, cookie-av 문자열을 무시하고 이 알고리즘의 1단계로 돌아간다.¶

7. 다음 하위 절의 요구사항에 따라 attribute-name과 attribute-value를 처리한다. (인식되지 않는 attribute-name을 가진 속성은 무시된다는 점에 유의하라.)¶

8. 이 알고리즘의 1단계로 돌아간다.¶

사용자 에이전트가 set-cookie-string 파싱을 마치면, 사용자 에이전트는 request-uri로부터 name cookie-name, value cookie-value, attributes cookie-attribute-list를 가진 "쿠키를 수신했다"고 말한다. (쿠키 수신으로 트리거되는 추가 요구사항은 5.7절 참조.)¶

 * The HTTP request associated with the retrieval uses a "safe"
   method.

 * At least one of the following is true:

   1.  The HTTP request associated with the retrieval uses a "safe"
       method.

   2.  The cookie's same-site-flag is "Default" and the amount of
       time elapsed since the cookie's creation-time is at most a
       duration of the user agent's choosing.

5.7. 저장 모델

사용자 에이전트는 각 쿠키에 대해 다음 필드를 저장한다: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, http-only-flag, same-site-flag.¶

사용자 에이전트가 request-uri로부터 name이 cookie-name, value가 cookie-value, attributes가 cookie-attribute-list인 "쿠키를 수신"하면, 사용자 에이전트는 다음과 같이 쿠키를 처리해야 한다(MUST):¶

1. 사용자 에이전트는 수신한 쿠키 전체를 무시할 수 있다(MAY). 5.3절을 참조하라.¶

2. cookie-name이 비어 있고 cookie-value도 비어 있으면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

3. cookie-name 또는 cookie-value가 %x00-08 / %x0A-1F / %x7F 문자(HTAB을 제외한 CTL 문자)를 포함하면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

4. cookie-name과 cookie-value 길이의 합이 4096 옥텟보다 크면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

5. name이 cookie-name이고 value가 cookie-value인 새 쿠키를 생성한다. creation-time과 last-access-time을 현재 날짜와 시간으로 설정한다.¶

6. cookie-attribute-list가 attribute-name이 "Max-Age"인 속성을 포함하면:¶

   1. 쿠키의 persistent-flag를 true로 설정한다.¶

   2. 쿠키의 expiry-time을 cookie-attribute-list에서 attribute-name이 "Max-Age"인 마지막 속성의 attribute-value로 설정한다.¶

   그렇지 않고, cookie-attribute-list가 attribute-name이 "Expires"인 속성을 포함하며(attribute-name이 "Max-Age"인 속성은 포함하지 않으면):¶

   1. 쿠키의 persistent-flag를 true로 설정한다.¶

   2. 쿠키의 expiry-time을 cookie-attribute-list에서 attribute-name이 "Expires"인 마지막 속성의 attribute-value로 설정한다.¶

   그렇지 않으면:¶

   1. 쿠키의 persistent-flag를 false로 설정한다.¶

   2. 쿠키의 expiry-time을 표현 가능한 가장 늦은 날짜로 설정한다.¶

7. cookie-attribute-list가 attribute-name이 "Domain"인 속성을 포함하면:¶

   1. domain-attribute를 cookie-attribute-list에서 attribute-name이 "Domain"이고 attribute-value 길이가 1024 옥텟 이하인 마지막 속성의 attribute-value로 둔다. (앞에 %x2E(".")가 있으면, 그 문자가 허용되지 않더라도 무시된다는 점에 유의하라.)¶

   그렇지 않으면:¶

   1. domain-attribute를 빈 문자열로 둔다.¶

8. domain-attribute가 CHAR에 속하지 않는 문자를 포함하면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

9. 사용자 에이전트가 "public suffixes"를 거부하도록 구성되어 있고 domain-attribute가 public suffix이면:¶

   1. request-host-canonical을 정규화된 request-host로 둔다.¶

   2. request-host 정규화에 실패하면 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

   3. domain-attribute가 request-host-canonical과 동일하면:¶

      1. domain-attribute를 빈 문자열로 둔다.¶

      그렇지 않으면:¶

      1. 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

   참고: 이 단계는 attacker.example이 Domain 속성이 "example"인 쿠키를 설정하여 site.example의 무결성을 방해하는 것을 방지한다.¶

10. domain-attribute가 비어 있지 않으면:¶

    1. request-host-canonical이 domain-attribute와 domain-match하지 않으면(5.1.3절 참조):¶

       1. 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

       그렇지 않으면:¶

       1. 쿠키의 host-only-flag를 false로 설정한다.¶

       2. 쿠키의 domain을 domain-attribute로 설정한다.¶

    그렇지 않으면:¶

    1. 쿠키의 host-only-flag를 true로 설정한다.¶

    2. 쿠키의 domain을 request-host-canonical로 설정한다.¶

11. cookie-attribute-list가 attribute-name이 "Path"인 속성을 포함하면, 쿠키의 path를 cookie-attribute-list에서 attribute-name이 "Path"이고 attribute-value 길이가 1024 옥텟 이하인 마지막 속성의 attribute-value로 설정한다. 그렇지 않으면 쿠키의 path를 request-uri의 default-path로 설정한다.¶

12. cookie-attribute-list가 attribute-name이 "Secure"인 속성을 포함하면, 쿠키의 secure-only-flag를 true로 설정한다. 그렇지 않으면 쿠키의 secure-only-flag를 false로 설정한다.¶

13. request-uri가 (사용자 에이전트가 정의한) "secure" 연결을 나타내지 않고, 쿠키의 secure-only-flag가 true이면, 이 단계들을 중단하고 쿠키 전체를 무시한다.¶

14. cookie-attribute-list가 attribute-name이 "HttpOnly"인 속성을 포함하면, 쿠키의 http-only-flag를 true로 설정한다. 그렇지 않으면 쿠키의 http-only-flag를 false로 설정한다.¶

15. 쿠키가 "non-HTTP" API에서 수신되었고 쿠키의 http-only-flag가 true이면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

16. 쿠키의 secure-only-flag가 false이고 request-uri가 "secure" 연결을 나타내지 않으면, 쿠키 저장소에 다음 기준을 모두 만족하는 쿠키가 하나 이상 있는 경우 이 알고리즘을 중단하고 쿠키 전체를 무시한다:¶

    1. 그 이름이 새로 생성된 쿠키의 이름과 일치한다.¶

    2. 그 secure-only-flag가 true이다.¶

    3. 그 domain이 새로 생성된 쿠키의 domain과 domain-match하거나(5.1.3절 참조), 그 반대이다.¶

    4. 새로 생성된 쿠키의 path가 기존 쿠키의 path와 path-match한다.¶

    참고: 경로 비교는 대칭적이지 않다. 이는 새로 생성된 비보안 쿠키가 기존 보안 쿠키를 덮어쓰지 않도록 보장하여, cookie-fixing 공격에 대한 일부 완화를 제공한다. 즉, 이름이 'a'이고 경로가 '/login'인 기존 보안 쿠키가 있을 때, 이름이 'a'인 비보안 쿠키는 '/' 또는 '/foo' 경로에 대해 설정될 수 있지만, '/login' 또는 '/login/en' 경로에 대해서는 설정될 수 없다.¶

17. cookie-attribute-list가 attribute-name이 "SameSite"이고 attribute-value가 "Strict", "Lax" 또는 "None"인 속성을 포함하면, 쿠키의 same-site-flag를 cookie-attribute-list에서 attribute-name이 "SameSite"인 마지막 속성의 attribute-value로 설정한다. 그렇지 않으면 쿠키의 same-site-flag를 "Default"로 설정한다.¶

18. 쿠키의 same-site-flag가 "None"이 아니면:¶

    1. 쿠키가 "non-HTTP" API에서 수신되었고, 그 API가 navigable의 active document에서 호출되었으며 해당 "site for cookies"가 top-level origin과 same-site가 아니면, 이 알고리즘을 중단하고 새로 생성된 쿠키 전체를 무시한다.¶

    2. 쿠키가 "same-site" 요청에서 수신되었으면 (5.2절에 정의됨), 나머지 하위 단계를 건너뛰고 쿠키 처리를 계속한다.¶

    3. 쿠키가 top-level traversable [HTML]을 탐색하는 요청에서 수신되었으면 (예: 요청의 "reserved client"가 null이거나, 그 "target browsing context"의 navigable이 top-level traversable인 환경인 경우), 나머지 하위 단계를 건너뛰고 쿠키 처리를 계속한다.¶

       참고: 최상위 탐색은 새 쿠키가 탐색 전에 이미 존재했다면 요청과 함께 전송되지 않았을 경우라도, 어떤 SameSite 값이든 가진 쿠키를 생성할 수 있다.¶

    4. 이 알고리즘을 중단하고 새로 생성된 쿠키 전체를 무시한다.¶

19. 쿠키의 "same-site-flag"가 "None"이면, 쿠키의 secure-only-flag가 true가 아닌 한 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

20. cookie-name이 대소문자를 구분하지 않고 문자열 "__Secure-"와 일치하는 것으로 시작하면, 쿠키의 secure-only-flag가 true가 아닌 한 이 알고리즘을 중단하고 쿠키 전체를 무시한다.¶

21. cookie-name이 대소문자를 구분하지 않고 문자열 "__Host-"와 일치하는 것으로 시작하면, 쿠키가 다음 기준을 모두 만족하지 않는 한 이 알고리즘을 중단하고 쿠키 전체를 무시한다:¶

    1. 쿠키의 secure-only-flag가 true이다.¶

    2. 쿠키의 host-only-flag가 true이다.¶

    3. cookie-attribute-list가 attribute-name이 "Path"인 속성을 포함하고, 쿠키의 path가 /이다.¶

22. cookie-name이 비어 있고 다음 조건 중 하나가 true이면, 이 알고리즘을 중단하고 쿠키 전체를 무시한다:¶

    • cookie-value가 대소문자를 구분하지 않고 문자열 "__Secure-"와 일치하는 것으로 시작한다¶

    • cookie-value가 대소문자를 구분하지 않고 문자열 "__Host-"와 일치하는 것으로 시작한다¶

23. 쿠키 저장소가 새로 생성된 쿠키와 동일한 name, domain, host-only-flag, path를 가진 쿠키를 포함하면:¶

    1. old-cookie를 새로 생성된 쿠키와 동일한 name, domain, host-only-flag, path를 가진 기존 쿠키로 둔다. (이 알고리즘은 그러한 쿠키가 최대 하나만 존재한다는 불변식을 유지한다는 점에 유의하라.)¶

    2. 새로 생성된 쿠키가 "non-HTTP" API에서 수신되었고 old-cookie의 http-only-flag가 true이면, 이 알고리즘을 중단하고 새로 생성된 쿠키 전체를 무시한다.¶

    3. 새로 생성된 쿠키의 creation-time을 old-cookie의 creation-time과 일치하도록 업데이트한다.¶

    4. 쿠키 저장소에서 old-cookie를 제거한다.¶

24. 새로 생성된 쿠키를 쿠키 저장소에 삽입한다.¶

쿠키의 만료 날짜가 과거이면 그 쿠키는 "expired"이다.¶

쿠키 저장소에 만료된 쿠키가 언제든 존재하면, 사용자 에이전트는 쿠키 저장소에서 모든 만료된 쿠키를 제거해야 한다(MUST).¶

어떤 domain 필드를 공유하는 쿠키의 수가 구현에서 정의한 상한(예: 50개의 쿠키)을 초과하면, 사용자 에이전트는 언제든 쿠키 저장소에서 "초과 쿠키 제거"를 할 수 있다(MAY).¶

쿠키 저장소가 미리 정해진 상한(예: 총 3000개의 쿠키)을 초과하면, 사용자 에이전트는 언제든 쿠키 저장소에서 "초과 쿠키 제거"를 할 수 있다(MAY).¶

사용자 에이전트가 쿠키 저장소에서 초과 쿠키를 제거할 때, 사용자 에이전트는 다음 우선순위 순서로 쿠키를 제거해야 한다(MUST):¶

1. 만료된 쿠키.¶

2. secure-only-flag가 false이고, 미리 정해진 수보다 많은 다른 쿠키와 domain 필드를 공유하는 쿠키.¶

3. 미리 정해진 수보다 많은 다른 쿠키와 domain 필드를 공유하는 쿠키.¶

4. 모든 쿠키.¶

두 쿠키의 제거 우선순위가 같으면, 사용자 에이전트는 last-access-time이 가장 이른 쿠키를 먼저 제거해야 한다(MUST).¶

"현재 세션이 끝나면"(사용자 에이전트가 정의한 대로), 사용자 에이전트는 persistent-flag가 false로 설정된 모든 쿠키를 쿠키 저장소에서 제거해야 한다(MUST).¶

5.8. 검색 모델

이 절은 쿠키 저장소에서 cookie-string 형태로 쿠키를 검색하는 방식을 정의한다. "retrieval"은 cookie-string 생성이 필요한 모든 이벤트이다. 예를 들어, HTTP 요청을 위한 Cookie 헤더 필드를 만들기 위해 retrieval이 발생할 수 있고, 쿠키에 대한 접근을 제공하는 "non-HTTP" API 호출에서 cookie-string을 반환하기 위해 retrieval이 필요할 수도 있다. retrieval에는 관련 URI, same-site 상태, type이 있으며, 이들은 retrieval의 유형에 따라 아래에 정의된다.¶

6.1. 제한

실제 사용자 에이전트 구현에는 저장할 수 있는 쿠키의 수와 크기에 제한이 있다. 범용 사용자 에이전트는 다음 최소 기능을 각각 제공하는 것이 좋다(SHOULD):¶

• 도메인당 최소 50개의 쿠키.¶

• 총 최소 3000개의 쿠키.¶

사용자 에이전트는 저장하는 쿠키의 최대 수를 제한할 수 있으며, 언제든 어떤 쿠키든 제거할 수 있다(사용자의 요청에 의해서든 구현 제한 때문이든).¶

쿠키 최대 수에 대한 제한은 저장된 쿠키의 총 크기도 제한한다는 점에 유의하라. 이는 5.6절에서 반드시 적용되어야 하는 길이 제한 때문이다.¶

서버는 이러한 구현 제한에 도달하는 것을 피하고, 모든 요청에 Cookie 헤더 필드가 포함됨으로 인한 네트워크 대역폭을 최소화하며, 서버 헤더 필드 제한에 도달하는 것을 피하기 위해 가능한 한 적고 작은 쿠키를 사용하는 것이 좋다(SHOULD)(4.2.1절 참조).¶

사용자 에이전트가 언제든 어떤 쿠키든 제거할 수 있으므로, 사용자 에이전트가 Cookie 헤더 필드에서 하나 이상의 쿠키를 반환하지 못하는 경우 서버는 우아하게 성능을 낮추는 것이 좋다(SHOULD).¶

6.2. 응용 프로그래밍 인터페이스

Cookie 및 Set-Cookie 헤더 필드가 이처럼 난해한 처리를 사용하는 한 가지 이유는, 많은 플랫폼(서버와 사용자 에이전트 모두)이 쿠키에 대해 문자열 기반 응용 프로그래밍 인터페이스(API)를 제공하여, 애플리케이션 계층 프로그래머가 Cookie 및 Set-Cookie 헤더 필드에서 사용하는 구문을 생성하고 파싱해야 하기 때문이다. 많은 프로그래머가 이를 잘못 처리했고, 그 결과 상호운용성 문제가 발생했다.¶

쿠키에 문자열 기반 API를 제공하는 대신, 플랫폼은 더 의미론적인 API를 제공하는 것이 유리할 것이다. 특정 API 설계를 권장하는 것은 이 문서의 범위를 벗어나지만, 직렬화된 날짜 문자열 대신 추상적인 "Date" 객체를 수락하는 데는 분명한 이점이 있다.¶

7.1. 제3자 쿠키

"third-party" 또는 cross-site 쿠키는 기본 리소스(보통 사용자가 보고 있는 웹 페이지)를 호스팅하는 서버와 다른 서버에서 얻은 삽입된 콘텐츠(예: scripts, images, stylesheets, frames)와 관련된 쿠키이다. 제3자 쿠키는 흔히 서로 다른 사이트에서 사용자의 활동을 상관시키는 데 사용된다.¶

고유한 개인정보 보호 문제 때문에, 대부분의 사용자 에이전트는 이제 다양한 방식으로 제3자 쿠키를 제한한다. 일부는 제3자 Set-Cookie 헤더 필드 처리를 거부하고 제3자 Cookie 헤더 필드 전송을 거부하여 제3자 쿠키를 완전히 차단한다. 일부는 first-party 컨텍스트에 따라 쿠키를 분할하여, 탐색 중인 사이트에 따라 서로 다른 쿠키가 전송되게 한다. 일부는 사용자 에이전트 쿠키 정책 및/또는 사용자 제어에 따라 쿠키를 차단한다.¶

이 문서는 특정 접근 방식을 지지하거나 요구하지 않지만, 사용자 에이전트가 호환성 제약이 허용하는 한 가능한 한 제한적인 제3자 쿠키 정책을 채택할 것을 권장한다(RECOMMENDED). 따라서 리소스는 예측 가능한 미래 동안 사용자 에이전트가 제3자 쿠키를 일관되게 처리할 것이라고 의존할 수 없다.¶

7.2. 쿠키 정책

사용자 에이전트는 쿠키가 사용되거나 무시될 수 있는 방식에 대한 제한으로 구성된 쿠키 정책을 적용할 수 있다(MAY)(5.3절 참조).¶

쿠키 정책은 사용자 에이전트가 쿠키 접근을 허용할 도메인 또는 당사자, 즉 first party 및 third party(7.1절 참조)를 규율할 수 있다. 정책은 쿠키 크기, 쿠키 만료(5.5절 참조), 도메인당 쿠키 수 또는 총 쿠키 수에 대한 제한도 정의할 수 있다.¶

권장되는 쿠키 만료 상한은 400일이다. 사용자 에이전트는 더 짧은 데이터 보존 기간을 적용하기 위해 더 낮은 제한을 설정하거나, 적절한 경우 더 긴 보존을 지원하기 위해 제한을 더 높게 설정할 수 있다(예: HTTPS를 통한 서버 간 통신).¶

제한적인 쿠키 정책의 목표는 흔히 보안 또는 개인정보 보호를 개선하는 것이다. 사용자 에이전트는 사용자가 쿠키 정책을 변경할 수 있도록 허용하는 경우가 많다 (7.3절 참조).¶

7.3. 사용자 제어

사용자 에이전트는 쿠키 저장소에 저장된 쿠키를 관리하기 위한 메커니즘을 사용자에게 제공하는 것이 좋다(SHOULD). 예를 들어, 사용자 에이전트는 지정된 기간 동안 수신된 모든 쿠키 또는 특정 도메인과 관련된 모든 쿠키를 사용자가 삭제할 수 있게 할 수 있다. 또한 많은 사용자 에이전트는 사용자가 쿠키 저장소에 저장된 쿠키를 검사할 수 있게 하는 사용자 인터페이스 요소를 포함한다.¶

사용자 에이전트는 쿠키를 비활성화하기 위한 메커니즘을 사용자에게 제공하는 것이 좋다(SHOULD). 쿠키가 비활성화되면, 사용자 에이전트는 나가는 HTTP 요청에 Cookie 헤더 필드를 포함해서는 안 되며(MUST NOT), 들어오는 HTTP 응답의 Set-Cookie 헤더 필드를 처리해서는 안 된다(MUST NOT).¶

사용자 에이전트는 쿠키 정책을 변경할 수 있는 방법을 제공할 수 있다(MAY) (7.2절 참조).¶

사용자 에이전트는 세션 간 쿠키의 영구 저장을 방지하는 옵션을 사용자에게 제공할 수 있다(MAY). 이렇게 구성된 경우, 사용자 에이전트는 수신한 모든 쿠키를 persistent-flag가 false로 설정된 것처럼 취급해야 한다(MUST). 일부 인기 있는 사용자 에이전트는 이 기능을 "private browsing" 모드 [Aggarwal2010]를 통해 노출한다.¶

7.4. 만료 날짜

서버가 쿠키의 만료 날짜를 먼 미래로 설정할 수는 있지만, 대부분의 사용자 에이전트는 실제로 여러십 년 동안 쿠키를 유지하지 않는다. 불필요하게 긴 만료 기간을 선택하기보다, 서버는 쿠키의 목적에 따라 합리적인 쿠키 만료 기간을 선택하여 사용자의 개인정보 보호를 증진하는 것이 좋다(SHOULD). 예를 들어, 일반적인 세션 식별자는 2주 후에 만료되도록 설정하는 것이 합리적일 수 있다.¶

8.1. 개요

쿠키에는 여러 보안상 함정이 있다. 이 절은 그중 몇 가지 더 두드러진 문제를 개관한다.¶

특히 쿠키는 개발자가 인증을 위해 주변 권한에 의존하도록 장려하여, 종종 cross-site request forgery [CSRF]와 같은 공격에 취약해진다. 또한 개발자는 세션 식별자를 쿠키에 저장할 때 세션 고정 취약점을 만드는 경우가 많다.¶

HTTPS에서 사용되는 것과 같은 전송 계층 암호화는 쿠키에 대한 네트워크 공격에 대해 상당한 방어 계층을 제공한다. 그러나 쿠키 프로토콜 자체의 본질적인 취약점 때문에 네트워크 공격자가 피해자의 쿠키를 얻거나 변경하는 것을 완전히 방지하기에는 충분하지 않다(아래의 "약한 기밀성" 및 "약한 무결성" 참조). 또한 기본적으로 쿠키는 HTTPS와 함께 사용되더라도 네트워크 공격자로부터의 기밀성이나 무결성을 제공하지 않는다. 이는 쿠키가 보호 속성을 명시적으로 지정해야 함을 의미한다. 예를 들어, 다음 쿠키는:¶

Set-Cookie: a=b ¶

Secure 속성을 지정하지 않으므로, 생성된 원래 연결 유형과 관계없이 보안 연결과 비보안 연결 모두에서 접근 가능하다. 이러한 동작은 공격자가 쿠키를 읽거나 수정할 수 있게 할 수 있다.¶

8.2. 주변 권한

사용자를 인증하기 위해 쿠키를 사용하는 서버는 보안 취약점을 겪을 수 있다. 일부 사용자 에이전트가 원격 당사자가 사용자 에이전트에서 HTTP 요청을 발행할 수 있게 하기 때문이다(예: HTTP 리다이렉트 또는 HTML 양식을 통해). 이러한 요청을 발행할 때, 사용자 에이전트는 원격 당사자가 쿠키의 내용을 알지 못하더라도 쿠키를 첨부하며, 이로 인해 원격 당사자가 부주의한 서버에서 권한을 행사할 수 있게 될 수 있다.¶

이 보안 우려는 여러 이름(예: cross-site request forgery, confused deputy)으로 불리지만, 문제는 쿠키가 주변 권한의 한 형태라는 데서 비롯된다. 쿠키는 서버 운영자가 지정(URL 형식)과 권한 부여(쿠키 형식)를 분리하도록 장려한다. 그 결과 사용자 에이전트는 공격자가 지정한 리소스에 대해 권한 부여를 제공할 수 있으며, 서버 또는 그 클라이언트가 마치 사용자가 권한을 부여한 것처럼 공격자가 지정한 작업을 수행하게 할 수 있다.¶

권한 부여에 쿠키를 사용하는 대신, 서버 운영자는 URL을 capability로 취급하여 지정과 권한 부여를 얽어 두는 방식을 고려할 수 있다. 이 접근법은 비밀을 쿠키에 저장하는 대신 URL에 저장하여, 원격 엔터티가 비밀 자체를 제공하도록 요구한다. 이 접근법이 만병통치약은 아니지만, 이러한 원칙을 신중하게 적용하면 더 견고한 보안으로 이어질 수 있다.¶

8.3. 평문

보안 채널(예: TLS [TLS13])을 통해 전송되지 않는 한, Cookie 및 Set-Cookie 헤더 필드의 정보는 평문으로 전송된다.¶

1. 이러한 헤더 필드로 전달되는 모든 민감한 정보는 도청자에게 노출된다.¶

2. 악의적인 중개자가 어느 방향으로든 이동하는 동안 헤더 필드를 변경할 수 있으며, 그 결과는 예측할 수 없다.¶

서버는 쿠키를 사용자 에이전트로 전송할 때(보안 채널을 통해 쿠키를 보내는 경우에도) 쿠키의 내용을 암호화하고 서명하는 것이 좋다(SHOULD)(서버가 원하는 어떤 형식이든 사용). 그러나 쿠키 내용을 암호화하고 서명하더라도 공격자가 한 사용자 에이전트에서 다른 사용자 에이전트로 쿠키를 이식하거나 나중에 쿠키를 재생하는 것을 방지하지는 못한다.¶

모든 쿠키의 내용을 암호화하고 서명하는 것에 더하여, 더 높은 수준의 보안을 요구하는 서버는 보안 채널에서만 Cookie 및 Set-Cookie 헤더 필드를 사용하는 것이 좋다(SHOULD). 보안 채널에서 쿠키를 사용할 때, 서버는 모든 쿠키에 Secure 속성(4.1.2.5절 참조)을 설정하는 것이 좋다(SHOULD). 서버가 Secure 속성을 설정하지 않으면, 보안 채널이 제공하는 보호는 대체로 무의미해진다.¶

예를 들어, 세션 식별자를 쿠키에 저장하고 일반적으로 HTTPS를 통해 접근되는 웹메일 서버를 생각해 보자. 서버가 쿠키에 Secure 속성을 설정하지 않으면, 능동적 네트워크 공격자는 사용자 에이전트에서 나가는 모든 HTTP 요청을 가로채어 그 요청을 HTTP를 통해 웹메일 서버로 리다이렉트할 수 있다. 웹메일 서버가 HTTP 연결을 수신하지 않더라도, 사용자 에이전트는 여전히 요청에 쿠키를 포함한다. 능동적 네트워크 공격자는 이러한 쿠키를 가로채고 서버에 대해 재생하여 사용자의 이메일 내용을 알 수 있다. 반대로 서버가 쿠키에 Secure 속성을 설정했다면, 사용자 에이전트는 평문 요청에 쿠키를 포함하지 않았을 것이다.¶

8.4. 세션 식별자

세션 정보를 쿠키에 직접 저장하는 대신(그 정보가 공격자에게 노출되거나 재생될 수 있음), 서버는 일반적으로 nonce(또는 "session identifier")를 쿠키에 저장한다. 서버가 nonce가 포함된 HTTP 요청을 받으면, 서버는 nonce를 키로 사용하여 쿠키와 관련된 상태 정보를 조회할 수 있다.¶

세션 식별자 쿠키를 사용하면, 공격자가 쿠키의 내용을 알게 되더라도 공격자가 초래할 수 있는 피해가 제한된다. nonce는 서버와 상호작용하는 데에만 유용하기 때문이다(nonce가 아닌 쿠키 내용은 그 자체로 민감할 수 있음). 더 나아가 단일 nonce를 사용하면, 공격자가 서버와의 두 상호작용에서 얻은 쿠키 내용을 "splicing"하여 서버가 예기치 않게 동작하게 하는 것을 방지한다.¶

세션 식별자를 사용하는 데 위험이 없는 것은 아니다. 예를 들어, 서버는 "session fixation" 취약점을 피하도록 주의하는 것이 좋다(SHOULD). 세션 고정 공격은 세 단계로 진행된다. 첫째, 공격자는 자신의 사용자 에이전트에서 피해자의 사용자 에이전트로 세션 식별자를 이식한다. 둘째, 피해자는 그 세션 식별자를 사용해 서버와 상호작용하며, 세션 식별자에 사용자의 자격 증명이나 기밀 정보를 부여할 수 있다. 셋째, 공격자는 그 세션 식별자를 사용해 서버와 직접 상호작용하여 사용자의 권한 또는 기밀 정보를 얻을 수 있다.¶

8.5. 약한 기밀성

쿠키는 포트별 격리를 제공하지 않는다. 한 포트에서 실행되는 서비스가 쿠키를 읽을 수 있으면, 같은 서버의 다른 포트에서 실행되는 서비스도 그 쿠키를 읽을 수 있다. 한 포트의 서비스가 쿠키를 쓸 수 있으면, 같은 서버의 다른 포트에서 실행되는 서비스도 그 쿠키를 쓸 수 있다. 이러한 이유로 서버는 같은 호스트의 서로 다른 포트에서 서로 신뢰하지 않는 서비스를 동시에 실행하면서 보안에 민감한 정보를 저장하는 데 쿠키를 사용하지 않는 것이 좋다(SHOULD NOT).¶

쿠키는 scheme별 격리를 제공하지 않는다. 가장 흔히 http 및 https scheme과 함께 사용되지만, 주어진 호스트의 쿠키는 ftp 및 gopher와 같은 다른 scheme에서도 사용 가능할 수 있다. 이러한 scheme별 격리 부재는 쿠키 접근을 허용하는 비HTTP API(예: HTML의 document.cookie API)에서 가장 분명하지만, scheme별 격리 부재는 실제로 쿠키 자체를 처리하기 위한 요구사항에도 존재한다 (예: HTTP를 통해 gopher scheme의 URI를 검색하는 경우를 생각해 보라).¶

쿠키는 항상 path별 격리를 제공하지는 않는다. 네트워크 수준 프로토콜은 한 path에 저장된 쿠키를 다른 path로 보내지 않지만, 일부 사용자 에이전트는 HTML의 document.cookie API와 같은 비HTTP API를 통해 쿠키를 노출한다. 이러한 사용자 에이전트 중 일부(예: 웹 브라우저)는 서로 다른 path에서 받은 리소스를 격리하지 않기 때문에, 한 path에서 검색된 리소스가 다른 path에 저장된 쿠키에 접근할 수 있을 수 있다.¶

8.6. 약한 무결성

쿠키는 형제 도메인(및 그 하위 도메인)에 대한 무결성 보장을 제공하지 않는다. 예를 들어 foo.site.example과 bar.site.example을 생각해 보자. foo.site.example 서버는 Domain 속성이 "site.example"인 쿠키를 설정할 수 있으며 (bar.site.example이 설정한 기존 "site.example" 쿠키를 덮어쓸 수도 있음), 사용자 에이전트는 bar.site.example에 대한 HTTP 요청에 그 쿠키를 포함한다. 최악의 경우 bar.site.example은 이 쿠키를 자신이 직접 설정한 쿠키와 구별할 수 없다. foo.site.example 서버는 이 능력을 이용하여 bar.site.example에 대한 공격을 수행할 수 있을 수 있다.¶

Set-Cookie 헤더 필드가 Path 속성을 지원하더라도, Path 속성은 무결성 보호를 제공하지 않는다. 사용자 에이전트가 Set-Cookie 헤더 필드 안의 임의의 Path 속성을 수락하기 때문이다. 예를 들어 http://site.example/foo/bar에 대한 요청의 HTTP 응답은 Path 속성이 "/qux"인 쿠키를 설정할 수 있다. 따라서 서버는 같은 호스트의 서로 다른 path에서 서로 신뢰하지 않는 서비스를 동시에 실행하면서 보안에 민감한 정보를 저장하는 데 쿠키를 사용하지 않는 것이 좋다(SHOULD NOT).¶

능동적 네트워크 공격자는 http://site.example/의 응답을 가장하고 Set-Cookie 헤더 필드를 삽입함으로써 https://site.example/로 전송되는 Cookie 헤더 필드에 쿠키를 주입할 수도 있다. site.example의 HTTPS 서버는 이러한 쿠키를 자신이 HTTPS 응답에서 직접 설정한 쿠키와 구별할 수 없다. 능동적 네트워크 공격자는 site.example이 HTTPS만 사용하더라도 이 능력을 이용하여 site.example에 대한 공격을 수행할 수 있을 수 있다.¶

서버는 쿠키의 내용을 암호화하고 서명하거나 쿠키 이름에 __Secure- 접두사를 붙여 이러한 공격을 부분적으로 완화할 수 있다. 그러나 암호화를 사용하더라도 문제가 완전히 완화되지는 않는다. 공격자가 진짜 site.example 서버에서 받은 쿠키를 사용자의 세션에서 재생할 수 있으며, 그 결과는 예측할 수 없기 때문이다.¶

마지막으로, 공격자는 많은 수의 쿠키를 저장하여 사용자 에이전트가 쿠키를 삭제하도록 강제할 수 있을 수 있다. 사용자 에이전트가 저장 제한에 도달하면, 사용자 에이전트는 일부 쿠키를 제거할 수밖에 없다. 서버는 사용자 에이전트가 쿠키를 유지할 것이라고 의존해서는 안 된다(SHOULD NOT).¶

8.7. DNS에 대한 의존

쿠키는 보안을 위해 Domain Name System(DNS)에 의존한다. DNS가 부분적으로 또는 완전히 손상되면, 쿠키 프로토콜은 애플리케이션이 요구하는 보안 속성을 제공하지 못할 수 있다.¶

8.8. SameSite 쿠키

8.9. 공개 접미사 목록

쿠키의 경계는 사이트의 "registrable domain"에 의존하며, 이는 다시 도메인의 public suffix에 의존한다.¶

가능할 때마다, 사용자 에이전트는 [PSL]에 있는 Mozilla 프로젝트가 유지 관리하는 것과 같은 최신 public suffix list를 사용하는 것이 좋다(SHOULD).¶

그렇게 하지 않으면 악의적이거나 민감한 쿠키가 registrable domain 사이에서 누출될 수 있다.¶

9.1. Cookie

HTTP Field Name Registry([HttpFieldNameRegistry] 참조)는 다음 등록으로 업데이트되어야 한다:¶

헤더 필드 이름:

Cookie¶

적용 가능한 프로토콜:

http¶

상태:

standard¶

저자/변경 관리자:

IETF¶

명세 문서:

이 명세(5.8.1절)¶

9.2. Set-Cookie

HTTP Field Name Registry([HttpFieldNameRegistry] 참조)는 다음 등록으로 업데이트되어야 한다:¶

헤더 필드 이름:

Set-Cookie¶

적용 가능한 프로토콜:

http¶

상태:

standard¶

저자/변경 관리자:

IETF¶

명세 문서:

이 명세(5.6절)¶

9.3. "Cookie Attributes" 레지스트리

IANA는 쿠키 동작을 제어하는 데 사용되는 속성의 이름 공간을 정의하는 "Cookie Attributes" 레지스트리를 만들 것을 요청받는다. 이 레지스트리는 https://www.iana.org/assignments/cookie-attribute-names의 "Hypertext Transfer Protocol (HTTP) Cookie Attributes"라는 새 레지스트리 그룹에서 유지 관리되어야 한다.¶

10.1. 규범 참고문헌

[DOM-DOCUMENT-COOKIE]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML - Living Standard", 일자 없음, <https://html.spec.whatwg.org/#dom-document-cookie>. WHATWG

[HTTP]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, 2022년 6월, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1987년 11월, <https://www.rfc-editor.org/rfc/rfc1034>.

[RFC1123]

Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, 1989년 10월, <https://www.rfc-editor.org/rfc/rfc1123>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997년 3월, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4790]

Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, DOI 10.17487/RFC4790, 2007년 3월, <https://www.rfc-editor.org/rfc/rfc4790>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, 2008년 1월, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, 2010년 8월, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC6454]

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, 2011년 12월, <https://www.rfc-editor.org/rfc/rfc6454>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017년 6월, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017년 5월, <https://www.rfc-editor.org/rfc/rfc8174>.

[SAMESITE]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML Living Standard", 일자 없음, <https://html.spec.whatwg.org/#same-site>. WHATWG

[USASCII]

American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986년.

10.2. 정보 참고문헌

[Aggarwal2010]

Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, "An Analysis of Private Browsing Modes in Modern Browsers", 2010년, <http://www.usenix.org/events/sec10/tech/full_papers/Aggarwal.pdf>.

[app-isolation]

Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson, "App Isolation - Get the Security of Multiple Browsers with Just One", 2011년, <http://www.collinjackson.com/research/papers/appisolation.pdf>.

[CSRF]

Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, ACM CCS '08: Proceedings of the 15th ACM conference on Computer and communications security (pages 75-88), 2008년 10월, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

[FETCH]

van Kesteren, A., "Fetch Living Standard", 일자 없음, <https://fetch.spec.whatwg.org/>. WHATWG

[HTML]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML Living Standard", 일자 없음, <https://html.spec.whatwg.org/>. WHATWG

[HttpFieldNameRegistry]

"Hypertext Transfer Protocol (HTTP) Field Name Registry", 일자 없음, <https://www.iana.org/assignments/http-fields/>.

[prerendering]

Bentzel, C., "Chrome Prerendering", 일자 없음, <https://www.chromium.org/developers/design-documents/prerender>.

[PSL]

"Public Suffix List", 일자 없음, <https://publicsuffix.org/list/>.

[RFC2109]

Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, DOI 10.17487/RFC2109, 1997년 2월, <https://www.rfc-editor.org/rfc/rfc2109>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005년 1월, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, 2006년 10월, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC6265]

Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, 2011년 4월, <https://www.rfc-editor.org/rfc/rfc6265>.

[RFC7034]

Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-Options", RFC 7034, DOI 10.17487/RFC7034, 2013년 10월, <https://www.rfc-editor.org/rfc/rfc7034>.

[RFC9113]

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, 2022년 6월, <https://www.rfc-editor.org/rfc/rfc9113>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, 2022년 6월, <https://www.rfc-editor.org/rfc/rfc9114>.

[SERVICE-WORKERS]

Archibald, J. and M. Kruisselbrink, "Service Workers", 일자 없음, <https://www.w3.org/TR/service-workers/>.

[TLS13]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, 2018년 8월, <https://www.rfc-editor.org/rfc/rfc8446>.