Set-Cookie 属性の解釈
https://www.example.com/app/login へのログインに成功したとき，Web サーバが次のヘッダを返した。ブラウザが RFC 6265 に従って処理する場合，この Cookie の扱いとして，適切なものはどれか。
Set-Cookie: sid=8f3a2c91d7e4b6a0; Domain=example.com; Path=/app; HttpOnly- アHttpOnly 属性が指定されているので，http:// で始まる URL へのリクエストでは sid は送信されない。
- イPath 属性に /app が指定されているので，同じホストの /blog 配下のページに XSS 脆弱性があっても，そのページのスクリプトに sid 付きのリクエストを /app 宛てに送信させることはできない。
- ウExpires 属性も Max-Age 属性も指定されていないので，ブラウザは sid を保存せず，次のリクエストには送信しない。
- エDomain 属性に example.com が指定されているので，www.example.com だけでなく，shop.example.com など example.com のサブドメインへのリクエストにも sid が送信される。
正解と解説を見る
正解 エ
この問題の基礎知識
- Cookie の Domain 属性と Path 属性は送信するリクエストの範囲を，Expires 属性と Max-Age 属性は有効期限を決める。有効期限の指定がない Cookie は，ブラウザのセッションが終わるまで保持される。
- Domain 属性を省略した Cookie は発行元のホストだけに送られ，指定するとそのドメインとサブドメインにも送られる。Path 属性はリクエスト先の URI のパスで判定され，セキュリティ上の分離には使えない。
- Secure 属性は Cookie の送信を HTTPS など安全な通信路に限定し，HttpOnly 属性は JavaScript など HTTP 以外の API から Cookie を参照させないようにする。両者の役割は異なる。
アHttpOnly 属性が指定されているので，http:// で始まる URL へのリクエストでは sid は送信されない。
HttpOnly 属性は，スクリプトなど HTTP 以外の API から Cookie を参照させないための属性である。送信を TLS などの安全な通信路に限定するのは Secure 属性で，このヘッダには指定されていないので，http:// へのリクエストにも送信される。
イPath 属性に /app が指定されているので，同じホストの /blog 配下のページに XSS 脆弱性があっても，そのページのスクリプトに sid 付きのリクエストを /app 宛てに送信させることはできない。
Cookie を付けるかどうかはリクエスト先の URI のパスで判定されるので，/blog のスクリプトから /app 宛てに送ったリクエストにも sid が付く。RFC 6265 は，Path 属性をセキュリティのための分離として当てにできないとしている。
ウExpires 属性も Max-Age 属性も指定されていないので，ブラウザは sid を保存せず，次のリクエストには送信しない。
有効期限の属性がない Cookie は，ブラウザが定める現在のセッションが終わるまで保持される。保存されないわけではなく，セッション中の後続のリクエストには送信される。
エDomain 属性に example.com が指定されているので，www.example.com だけでなく，shop.example.com など example.com のサブドメインへのリクエストにも sid が送信される。正解
RFC 6265 では，Domain 属性が example.com なら example.com とそのサブドメインへのリクエストに Cookie を付ける。省略すれば発行元ホストだけに送られるので，セッション ID には通常 Domain 属性を付けない。
検証用の出典出典照合済み
RFC 6265 HTTP State Management Mechanism照合の根拠（5 件）
- ア（誤り）: HttpOnly はスクリプト等の非 HTTP API から隠す属性であり，http:// への送信は制限しない
The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs (such as a web browser API that exposes cookies to scripts).
RFC 6265 · Section 4.1.2.6（新しいタブで開きます） - ア（誤り）: 安全な通信路に送信を限定するのは Secure 属性（このヘッダには無い）
When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel
RFC 6265 · Section 4.1.2.5（新しいタブで開きます） - イ（誤り）: Path 属性はセキュリティのための分離として当てにできない（送信はリクエスト先 URI のパスで判定される）
Although seemingly useful for isolating cookies between different paths within a given host, the Path attribute cannot be relied upon for security (see Section 8).
RFC 6265 · Section 4.1.2.4（新しいタブで開きます） - ウ（誤り）: 有効期限属性のない Cookie はセッション終了まで保持される
If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent).
RFC 6265 · Section 4.1.2.2（新しいタブで開きます） - エ（正解）: Domain=example.com ならサブドメインへのリクエストにも Cookie が付く
For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.
RFC 6265 · Section 4.1.2.3（新しいタブで開きます）