深刻度：高Cookieのセキュリティ

Secure、HttpOnly、SameSite のCookieフラグ

セッションCookieは格好の標的です。Secure、HttpOnly、SameSite の3つの属性が、攻撃者がそれを盗んだり悪用したりできるかどうかを左右します。フラグが欠けていると、そのままセッション乗っ取りやCSRFにつながります。

これは何か

Secure はCookieをHTTPSでのみ送信します。HttpOnly はJavaScript（document.cookie）から隠します。SameSite は、クロスサイトのリクエストで送信するかどうかを制御します。

これらを組み合わせると攻撃対象領域が狭まります。攻撃者は、注入したスクリプトでCookieを読めず、HTTPで盗み見ることもできず、別のサイトから乗っかることもできなくなります。

HttpOnly がないと、あらゆるXSSのバグがセッションCookieを読み取り、ログイン中のセッションを攻撃者に渡してしまいます。Secure がないと、CookieはあらゆるプレーンHTTPのリクエストで漏れます。

SameSite がないと、ブラウザはクロスサイトのリクエストにCookieを付与します。これはCSRF攻撃が依存している仕組みそのものです。

セッションCookieに3つすべてを設定する

ほとんどのフレームワークは、Cookieを設定するときにこれらをオプションとして提供しています。

res.cookie("session", token, {
  secure: true,
  httpOnly: true,
  sameSite: "lax", // or "strict" for maximum protection
  path: "/",
});

Cookie名のプレフィックスを使う

Cookie名に __Host- を付けると、ブラウザは Secure、Path=/、Domain なしを要求します——セッションCookieにとって強力で、自ずと守られる基準になります。

SameSite=None には Secure が必要

本当にクロスサイトのCookieが必要な場合、SameSite=None は Secure も設定されているときにのみ有効になります。そうでないと、最近のブラウザはCookieを破棄します。

Lax は、トップレベルのナビゲーションは許可しつつ安全な既定値です。Strict はより厳格ですが、ユーザーが外部リンクから来てログイン済みを期待するフローを壊すことがあります。

HttpOnly はCookieを隠すことでXSSの被害を抑えますが、XSSそのものは防ぎません。強力なContent-Security-Policyと組み合わせてください。

AppSafeなら、この問題を含む数十項目を1回の無料スキャンでチェックできます。