HTTP Cookie の使用 - HTTP | MDN

このドキュメントを読みつつ cookie について復習（MDNは質の高いドキュメントで素晴らしい👏）。

重要だと思った部分を引用。

Cookieはステートフルな情報を記憶する

http がステートレスという特性があるので cookie という仕組みによってステートフルな情報の記憶を可能にしている。

HTTP Cookie (ウェブ Cookie、ブラウザー Cookie) は、サーバーがユーザーのウェブブラウザーに送信する小さなデータであり、ブラウザーに保存され、その後のリクエストと共に同じサーバーへ返送されます。一般的には、二つのリクエストが同じブラウザーから送信されたものであるかを知るために使用されます。例えば、ユーザーのログイン状態を維持することができます。Cookie は、ステートレスな HTTP プロトコルのためにステートフルな情報を記憶します。

以下の 3 つの用途がある。

  • セッション管理: ログイン、ショッピングカートの中身。
  • パーソナライゼーション: ユーザー設定（ログインしなくてもユーザー設定を cookie に保存して利用）
  • トラッキング: ユーザーの行動の記録（広告のトラッキングとかGAのユーザー分析とか）

今はストレージAPIを使うべき

Cookie は、クライアント側の汎用的な記憶領域として使用されたことがあります。これは他にクライアントへデータを保存する手段がなかった頃は合理的でしたが、現在では新しいストレージ API を使用することが推奨されています。

Cookie はすべてのリクエストで送信されるので、 (特にモバイルデータ通信で) 性能を悪化させる可能性があります。

クライアントストレージ向けの新しい API としては下記２つがある。

  • Web Storage API (localStorage および sessionStorage)

    • Web Storage API は、Cookie を使用するよりも直感的な方法で、ブラウザーがキーと値のペアを保存できる仕組みを提供します。

  • IndexedDB

    • IndexedDB は、ファイルや blob を含む大量の構造化データをクライアント側で保存するための低レベル API です。

Set-Cookie レスポンスヘッダーは、サーバーがユーザーエージェントへ Cookie を送信する

Set-Cookie: <cookie-name>=<cookie-value>

これを受け取ったブラウザ側は Cookie ヘッダに値を格納して次回のリクエストでサーバーに送信する。

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
  • セッション Cookie は現在のセッションが終了すると削除されます。ブラウザーはいつ「現在のセッション」が終わったと見なすかを定義し、ブラウザーによっては再起動時にセッションの復元を使用するため、セッションクッキーが無期限に持続することがあります。
  • 持続的 Cookie は、 Expires 属性で指定された時刻、または Max-Age で指定された期間が経過した後に削除されます。

Expiresが指定されたSet-Cookieの例:

Set-Cookie: id=a3fWa; Expires=Wed, 31 Oct 2021 07:28:00 GMT;

セッション固定攻撃の回避

セッションクッキーを再生成して再送することで流動させる（固定化を防ぐ）。

サイトがユーザーを認証する場合、ユーザーが認証するたびに、すでに存在するセッションクッキーも含めて、セッションクッキーを再生成して再送する必要があります。この手法は、第三者がユーザーのセッションを再利用するセッション固定攻撃を防ぐのに役立ちます。

Secure属性 & HttpOnly属性 を付ける

クッキーが安全に送信され、意図しない第三者やスクリプトからアクセスされないようにするには、 Secure 属性と HttpOnly 属性の2つの方法があります。

Domain属性

Domain 属性は、Cookie を受信することができるホストを指定します。指定されていない場合は、既定でクッキーを設定したのと同じオリジンとなり、サブドメインは除外されます。

Path属性

Path 属性は、 Cookie ヘッダーを送信するためにリクエストされた URL の中に含む必要がある URL のパスを示します。

SameSite 属性

SameSite 属性により、サーバーがオリジン間リクエスト (ここでサイトは登録可能なドメインによって定義されます) と一緒にクッキーを送るべきではないことを要求することができます。

CSRFの防御策として働く。

下記の３つの設定が可能。

  • Strict
  • Lax
  • None

機密情報 (認証を示す場合など) のために使用されたクッキーは、持続時間を短く、 SameSite 属性を Strict または Lax に設定してください。

下記も参照。

2020-01-21 SameSite none Cookie | TTIL

ファーストパーティCookie, サードパーティCookie

  • ファーストパーティCookie: Cookie のドメインが閲覧しているドメインと一致している場合
  • サードパーティ Cookie: 異なるドメインのCookie

サードパーティCookieによるトラッキング

ウェブページをホスティングしているサーバーがファーストパーティ Cookie を設定する一方で、ページには他のドメインのサーバーに保存されている画像やその他のコンポーネント (例えば、広告バナー) が含まれている場合があり、サードパーティクッキーが設定されることがあります。これらは主にウェブ上での広告やトラッキングに使用されます。

サードパーティのクッキー (またはトラッキングクッキー) は、他のブラウザーの設定や拡張機能によってもブロックされる場合があります。

GDPRなどの流れがある中、今後サードパーティクッキーはますます扱いにくいものになっていきそうだ。

ChromeサードパーティCookie終了後のリタゲ広告などの対処法