Secure Cookie フラグ.

Set-Cookie ヘッダーの Secure 属性は、Cookie を暗号化された接続に限定します。ブラウザはこの Cookie を平文 HTTP で送信することは決してないため、経路上の攻撃者がセッション Cookie を盗聴したり、被害者を http:// のサブリソースへ誘導して漏洩させたりする、古典的な傍受経路を塞げます。歴史的には、これが「サイドジャック」を可能にしていました。2010 年の Firesheep という Firefox 拡張機能は、開放された Wi-Fi 上で Facebook や Twitter のセッションをいとも簡単に乗っ取りましたが、これはまさにそれらの Cookie に Secure が欠けていたためであり、この事件が業界全体をサイト全体の HTTPS 化へと押し進めました。

Secure だけでは不十分です。HTTP 経由で注入できる攻撃者は、なお secure Cookie を上書きできます(「クッキートッシング」/固定化攻撃)。そこで RFC 6265bis は、2 つの堅牢化のためのプレフィックスを定義しています。__Secure-* という名前の Cookie は Secure を伴い、HTTPS オリジンから設定されなければなりません。__Host-* の Cookie はさらに Domain を省略し Path=/ を設定しなければならず、これによって Cookie が正確なホストに固定され、サブドメイン経由の注入を防ぎます。ブラウザは、これらの規則に違反するプレフィックス付き Cookie を黙って拒否します。Secure は HttpOnly、SameSite、狭いスコープ、そしてサイト全体の HSTS と組み合わせてください。なお、PortSwigger による 2025 年の「Cookie Chaos」の研究は、パーサーの癖によって一部のスタックではプレフィックスの強制を依然として回避できることを示しました。多層防御は引き続き不可欠です。

flowchart TD
  A[サーバが Cookie を設定] --> B{Secure 属性?}
  B -->|なし| C[HTTP + HTTPS で送信<br/>通信路上で盗聴可能]
  B -->|あり| D{リクエストのスキーム?}
  D -->|https://| E[Cookie を送信]
  D -->|http://| F[Cookie を送信しない]
  E --> G{名前のプレフィックス?}
  G -->|__Host-| H[Secure 必須、Domain なし、<br/>Path=/ - ホストに固定]
  G -->|__Secure-| I[Secure +<br/>HTTPS オリジン必須]
  G -->|なし| J[HTTP 注入で<br/>上書き可能]