Cookieのセキュリティを確認する方法:Secure、HttpOnly、SameSiteとCookieプレフィックス

誰かがあなたのサイトにログインすると、サーバーは通常、その人のブラウザにセッションCookieを渡します。それ以降は、そのCookieを持っている者がそのユーザーとして扱われます。Cookieの属性は、ブラウザがいつ、どの接続でCookieを送信するか、そしてページ上のスクリプトがそれを読み取れるかどうかを決めます。正しく設定するのに必要なのは設定1行ですが、設定を誤ると、小さなバグがアカウントの乗っ取りに発展しかねません。

重要な属性

Secure

Secure は、CookieをHTTPSでのみ送信するようブラウザに指示します。これがないと、Cookieが暗号化されていないHTTPリクエストに乗って送られることがあります。たとえば、誰かが https:// を付けずにドメインを入力し、リダイレクトが行われる前の時点です。その場合、同じネットワーク上にいる誰もがCookieを読み取れます。HTTPSのサイトでは、すべてのCookieを Secure にすべきです。

HttpOnly

HttpOnly は、CookieをJavaScript(document.cookie)から見えなくします。攻撃者がページにスクリプトを注入できたとしても、セッションCookieを読み取って外部に送るだけ、という手口は使えなくなります。セッションCookieと認証Cookieに指定してください。一部のフレームワークが意図的にJavaScriptへ公開しているCSRFトークンのように、自サイトのフロントエンドのコードが読み取る必要のあるCookieは HttpOnly にできませんが、それは想定どおりの動作です。

SameSite

SameSite は、リクエストが別のサイトから発生したときにCookieを送信するかどうかを制御します。

• SameSite=Strict: 自サイト内から始まったリクエストでのみ送信されます。最も安全ですが、メール内のリンクからサイトを訪れた人は、ログアウトしているように見える状態で到着します。
• SameSite=Lax: リンクのクリックのようなトップレベルのナビゲーションでは送信されますが、クロスサイトのフォーム送信(POST)、画像、フレームでは送信されません。セッションCookieの既定値として適しています。
• SameSite=None: あらゆるクロスサイトのコンテキストで送信されます。埋め込みウィジェットや一部のシングルサインオンのフローで必要です。必ず Secure と組み合わせなければならず、そうしないとブラウザはCookieを拒否します。

Chromium系のブラウザは、SameSite 属性のないCookieを Lax として扱いますが、すべてのブラウザが同じ動作をするわけではないので、明示的に設定してください。

DomainとPath

Domain を省略すると、Cookieはホスト限定になり、設定したホストそのものにだけ送信されます。Domain=example.com を設定すると、すべてのサブドメインと共有されます。そこには、別のホスティングに置かれたまま忘れられ、セキュリティが甘くなっているかもしれないサブドメインも含まれます。範囲を広げるのは、サブドメイン間でログイン状態を共有する必要が本当にある場合だけにしてください。

ExpiresとMax-Age

Expires も Max-Age もないCookieは、ブラウザのセッションの間だけ有効であることを想定していますが、セッションを復元するブラウザでは、それより長く残ることがあります。ログイン状態を保持する場合は、リスクに見合った有効期間を選び、サーバー側でもセッションを期限切れにするようにしてください。

Cookieプレフィックス:__Host- と __Secure-

Cookie名のプレフィックスを使うと、ブラウザがルールを代わりに強制してくれます。名前が __Secure- で始まるCookieは、Secure 属性があり、かつHTTPS経由で設定された場合にのみ受け入れられます。__Host- で始まるCookieはさらに厳格で、Secure であること、HTTPS経由で設定されること、Path=/ であること、そして Domain 属性がないことが求められます。これによってCookieは1つのホストに固定されるため、侵害されたサブドメインや管理の甘いサブドメインから上書きされることがありません。

サブドメイン間で共有する必要のないセッションCookieには、__Host- が現時点で最も強力な選択肢です: Set-Cookie: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/。

Cookieを確認する方法

1. ブラウザで。 開発者ツールを開き、Application(Chrome、Edge)またはStorage(Firefox)からCookiesに進み、自分のサイトを選択します。表には、各CookieのDomain、Path、Expires、HttpOnly、Secure、SameSiteの列が表示されます。
2. 生のレスポンスで。 Networkタブでドキュメントのリクエストをクリックし、Set-Cookie レスポンスヘッダーを読みます。ブラウザが拒否したかもしれない属性も含めて、サーバーが実際に送った内容がそのままわかります。
3. ログイン後に。 多くのサイトでは、重要なCookieはサインイン後やカートの作成時に初めて設定されます。そうしたページでもう一度確認してください。
4. チェッカーで。 Rudraの無料セキュリティチェッカーは、ページ自体のレスポンスに含まれる Set-Cookie ヘッダーを読み取り、HTTPSなのに Secure のないCookie、セッション用と思われるのに HttpOnly のないCookie、Secure を伴わない SameSite=None、SameSite の指定がないCookie、親ドメインをスコープとするCookieを報告します。

自動チェックには、知っておくべき限界が2つあります。まず、Cookieが「セッション用らしい」かどうかは名前から判断しています(sess、sid、token、auth などを含む名前)。そのため、これらの検出結果は信頼度「中」として報告されます。そのCookieが実際に何を保持しているかは、ご自身で確認してください。次に、見えるのはその1つのレスポンスで設定されたCookieだけです。あとからJavaScriptで設定されるCookie、ほかのページやログイン後に設定されるCookie、サードパーティが設定するCookieは対象外です。Cookieの値を読み取ったり保存したりすることは一切ありません。

主なプラットフォームでCookieの属性を設定する方法

• PHPのセッション: php.ini で session.cookie_secure = 1、session.cookie_httponly = 1、session.cookie_samesite = "Lax"(PHP 7.3以降)を設定するか、同じオプションを session_set_cookie_params() に渡します。
• Django: SESSION_COOKIE_SECURE = True と CSRF_COOKIE_SECURE = True を設定します。SESSION_COOKIE_HTTPONLY と SESSION_COOKIE_SAMESITE = "Lax" は、すでに既定値になっています。
• Express (Node.js): res.cookie("sid", value, { secure: true, httpOnly: true, sameSite: "lax" }) とするか、express-session の cookie オプションを使います。プロキシの背後で動かす場合は、接続がHTTPSであることをExpressが認識できるよう trust proxy を有効にします。
• WordPress: コアのログインCookieは HttpOnly で、サイトがHTTPSで動作していれば Secure も付きます。プラグインのCookieはまちまちなので、開発者ツールで確認し、属性が欠けていればプラグインの作者に問い合わせてください。
• 最後の手段としてのリバースプロキシ: nginxの proxy_cookie_flags(1.19.3以降)を使えば、変更できないアプリケーションのCookieに secure、httponly、samesite を追加できます。

よくある間違い

• 本番環境ではCookieを Secure にしているのに、ローカルではHTTPでしかテストせず、その属性を「一時的に」無効にしてしまう。
• Secure なしで SameSite=None を設定し、ブラウザにCookieを破棄されて、ログインや埋め込みが動かなくなる。
• 「念のため」とセッションCookieのスコープを親ドメインにする。
• セッショントークンを localStorage に保存する。注入されたスクリプトなら何でも読み取れてしまいます。HttpOnly のCookieのほうが安全です。
• Cookieの値に個人データを入れる。Cookieが保持すべきなのは識別子であって、情報そのものではありません。

Cookieは全体像の一部にすぎません。ヘッダー、HTTPS、そして受動的なテストの限界については、Webサイトのセキュリティを確認する方法をお読みください。