その「Cookie」、実は泥棒に鍵を渡していませんか？セッション管理の基本をマスターしよう
こんにちは。セキュリティの世界で長く泥臭い現場を見てきた者として、今日は「Cookie（クッキー）」という、Webサービスの命とも言える小さなデータの守り方についてお話しします。
「Cookieの設定なんて、なんとなくデフォルトのままにしている」という方、実は多いですよね。でも、その小さな設定の油断が、ログイン中のユーザーになりすます「セッションハイジャック」や、勝手に操作をされてしまう「CSRF（クロスサイト・リクエスト・フォージェリ）」という泥棒を招き入れる隙になってしまうのです。
今回は、難しい専門用語を身近な防犯に例えながら、一緒に紐解いていきましょう。
—
1. Cookieってそもそも何？：家に入るための「合鍵」です
Webサイトにログインすると、ブラウザに保存される小さなデータがCookieです。これは、あなたが「本人である」ことを証明する「合鍵」のようなもの。
一度ログインすれば、ページを移動するたびにパスワードを入れ直さなくていいのは、ブラウザがこの合鍵を毎回Webサイトに見せて、「この人はさっきログインした人ですよ」と伝えてくれているからなんです。
しかし、泥棒（攻撃者）はこの鍵を盗もうと虎視眈々と狙っています。どうやって守ればいいのか、3つの最強ガードを見ていきましょう。
—
2. 三種の神器：Cookieを守る最強の属性設定
Web開発の現場では、サーバーからブラウザにCookieを渡す際、いくつかの「注意書き」を添えることができます。これがセキュリティの防波堤になります。
① HttpOnly：鍵を「コピー」させない
`HttpOnly`属性を付けると、JavaScriptなどのプログラムからそのCookieにアクセスできなくなります。
- 防犯の例え： 鍵に「コピー禁止」の刻印を打つようなものです。たとえ悪意のあるプログラムがページ内に紛れ込んでも、そのプログラムは「鍵（Cookie）」を盗み出して外部に送ることができません。
② Secure：鍵を「安全な道」だけで運ぶ
`Secure`属性を付けると、HTTPS（暗号化された通信）でしかCookieを送らなくなります。
- 防犯の例え： 通信経路を「警備員付きの地下道」に限定するようなものです。暗号化されていない普通の道（HTTP）を通すと、途中で悪い人にパケットを覗き見されるリスクがありますが、これなら安心ですね。
③ SameSite：鍵を「見知らぬ人」には見せない
`SameSite`属性は、他のWebサイトからリクエストを送る際に、Cookieを送信するかどうかを決めます。`Strict`または`Lax`に設定するのが鉄則です。
- 防犯の例え： 「招待状を持っていない人には、家の中の様子を一切教えない」という門番を置くイメージです。これによって、無関係なサイトからの悪意ある操作（CSRF攻撃）をブロックできます。
—
3. 実践！設定サンプルコード
では、実際のWebアプリケーションではどう書けばいいのでしょうか。Node.js（Express）を例に見てみましょう。
// セッション設定の例
app.use(session({
name: ‘myAppSessionId’, // Cookieの名前は推測されにくいものに
secret: ‘秘密の合言葉’,
cookie: {
httpOnly: true, // JavaScriptからのアクセスを禁止
secure: true, // HTTPS通信でのみ送信を許可（本番環境では必須！）
sameSite: ‘lax’, // 外部サイトからの無防備な送信を制限
maxAge: 3600000 // 1時間で期限切れにする（長すぎる保持は危険です）
}
}));
※ 注意点： 開発環境では`secure: true`だとHTTPSの設定が面倒な場合がありますが、本番環境では絶対に有効化してください。ここを怠ると、せっかくのセキュリティが台無しになってしまいます。
—
4. 最後に：セキュリティは「完璧」ではなく「継続」
ここまで読んで、「これさえやれば100％安全！」と思ったあなた。実は、セキュリティに「絶対」はありません。しかし、こうした小さな設定を積み重ねることで、泥棒が「この家はセキュリティが硬そうだから、別の家を狙おう」と思うようになります。
攻撃者は、あなたのサイトの「一番弱いところ」を突いてきます。まずは今日学んだCookieの属性から、あなたのWebサイトの鍵を強化してみてください。
一歩ずつ、確実に。一緒に安全なインターネットを作っていきましょう！もし設定で迷うことがあれば、またいつでも聞きに来てくださいね。
コメント