【入門編】Set-Cookieヘッダーの属性(Secure, HttpOnly, SameSite) – HTTPプロトコル・通信規格実践ガイド

みなさん、こんにちは。ネットワークの深淵を覗き込み、パケットの鼓動を聴き続けている技術ライターです。

今日は、Webの世界で「身分証明書」として欠かせない存在である「Cookie(クッキー)」の話をしましょう。普段何気なく使っているWebサイトが、なぜログイン状態を維持できるのか。その裏側では、小さなテキストデータが郵便物のように行ったり来たりしているのです。

しかし、このCookie、油断すると「悪意ある第三者」に盗み出されたり、悪用されたりするリスクを孕んでいます。今日は、そのセキュリティを固めるための3つの最強の盾、`Secure`、`HttpOnly`、`SameSite`について、身近な例えを交えながら紐解いていきましょう。

—

そもそもCookieって何? 郵便配達で例えてみよう

Cookieは、Webサーバーがブラウザに渡す「会員証」のようなものです。

1. あなたがWebサイトを訪れる。
2. サーバーが「あなたは認証済みですよ」という手紙(Cookie)をブラウザに預ける。
3. 次回から、あなたはWebサイトを見るたびに、ポケットからその手紙を取り出して「これ僕です!」と提示する。

これがCookieの基本です。しかし、この手紙、誰でも覗き見できたり、勝手に別のサイトへ持ち出されたりしたら大変ですよね? そのために開発されたのが、今日紹介する「属性」という名のセキュリティ対策です。

—

1. Secure属性:手紙を「暗号化された箱」で守る

まずは、通信の盗聴対策です。インターネット上の通信は、何も対策をしないと誰かに覗き見されるリスクがあります。

`Secure`属性をつけると、「この手紙は、暗号化された安全なルート(HTTPS)を通るときしか渡さないで!」という制限がかかります。

  • 役割: 暗号化されていない通信(HTTP)では、Cookieを送信しなくなる。
  • イメージ: 封筒をそのまま渡すのではなく、絶対に中身が透けない頑丈な金庫に入れて運ぶようなものです。

サーバーからの応答ヘッダーの例
Set-Cookie: session_id=abc123xyz; Secure;
これにより、暗号化されていない通信ではこのCookieは使われなくなります

—

2. HttpOnly属性:JavaScriptという「スパイ」を排除する

次に、XSS(クロスサイトスクリプティング)対策です。これは非常に重要です。
Webサイト上では、JavaScriptというプログラムが動いています。通常、JavaScriptはCookieを読み取ることができるのですが、これが悪用されると、攻撃者が仕込んだ怪しいコードによってあなたのCookieが盗まれてしまいます。

`HttpOnly`属性をつけると、「この手紙は、ブラウザとサーバーのやり取り専用。JavaScriptという『スパイ』には絶対に触らせない!」という鍵がかかります。

  • 役割: JavaScriptからCookieへのアクセスを禁止する。
  • イメージ: 手紙を頑丈な引き出しに入れ、鍵をかけて「サーバー(郵便局)以外の人間は開けてはいけない」と決めるようなものです。

サーバーからの応答ヘッダーの例
Set-Cookie: session_id=abc123xyz; HttpOnly;
これで、ブラウザ上のJavaScriptからはこのCookieを盗み見ることができなくなります

—

3. SameSite属性:手紙の「持ち出し」を制限する

最後に、CSRF(クロスサイトリクエストフォージェリ)対策です。
これは、Aというサイトを見ているときに、悪意のあるBというサイトが勝手に「Aさん、これやっておいて!」と命令を送ってくる攻撃です。

`SameSite`属性は、「この手紙は、今いるサイトと同じ場所でしか使わせないよ」というルールです。

  • Lax(おすすめ): 基本的に「同じサイト内」でしか送らない。ただし、リンクをクリックして移動したときは例外的に許可する。
  • Strict: 「完全に同じサイト」以外からは、一切送信しない。
  • None: どこへでも送る(ただし`Secure`属性が必須)。
  • イメージ: 「この招待状は、この会場内でのみ有効です。他の会場へ行くときにポケットに入れたままにしないでくださいね」という門限のようなものですね。

サーバーからの応答ヘッダーの例
Set-Cookie: session_id=abc123xyz; SameSite=Lax;
これにより、外部サイトからの不正なリクエストでCookieが勝手に使われるのを防ぎます

—

まとめ:これからのWeb開発のスタンダード

最後に、今日学んだことをまとめておきましょう。

| 属性名 | 何を守る? | ざっくり言うと? |
| :— | :— | :— |
| Secure | 盗聴 | 暗号化通信でしか送らない! |
| HttpOnly | XSS攻撃 | プログラム(JavaScript)には触らせない! |
| SameSite | CSRF攻撃 | 他のサイトからの悪用を許さない! |

これら3つを正しく設定するだけで、Webサイトのセキュリティレベルは劇的に向上します。教科書を読み込むのも大切ですが、まずはブラウザの「開発者ツール(F12キー)」を開いて、皆さんが普段使っているサイトがどんなCookieを送っているのか覗いてみてください。

「あ、このサイトは`HttpOnly`がついているな」と発見するだけでも、ネットワークエンジニアへの第一歩です。一歩ずつ、着実に理解を深めていきましょう。

次回の記事では、これらの設定をNode.jsやGoのサーバーサイドでどう実装するか、具体的なコードを見ていこうと思います。それでは、また!

コメント

タイトルとURLをコピーしました