ReactとAPI構成におけるCSRF対策

クロスサイトリクエストフォージェリ（CSRF）は、悪意のある Web サイトがユーザーのブラウザをだまして、認証済みのリクエストを API に送信させる攻撃です。ブラウザはリクエストに Cookie を自動的に付加するため、サーバーはアプリからの正当なリクエストと、攻撃者のサイトからの偽造リクエストを区別できません。

Cookie は CSRF 脆弱性の根本原因です。ユーザーがアプリにログインすると、セッション Cookie がブラウザに保存されます。ユーザーが攻撃者のページを訪れると、攻撃者は API へのフォーム送信や fetch リクエストを発生させることができます。その際、ブラウザはセッション Cookie を自動的に含めるため、悪意のあるリクエストも認証されてしまいます。

SameSite Cookie 属性は、クロスサイトリクエストで Cookie を送信する条件をブラウザに指定します。値は3つあります。Lax（最新のブラウザでのデフォルト。クロスサイト POST はブロックしますが、GET は許可します）、Strict（GET ナビゲーションを含むすべてのクロスサイトリクエストをブロックします）、None（クロスサイトリクエストを許可しますが、HTTPS と Secure フラグが必要です）です。

SameSite=Lax は、クロスサイトの POST、PUT、DELETE、PATCH リクエストをブロックします。これらは変更操作に使われるメソッドです。API が読み取りには GET のみを使い、すべての変更操作に POST を使う場合、SameSite=Lax によって最新のブラウザ上の SPA では CSRF が実質的に防止されます。これは現在、多くのアプリケーションが依存している基本的な緩和策です。

Double Submit Cookie パターンは、サーバーがランダムな CSRF トークンを HttpOnly ではない Cookie に設定する CSRF 緩和策です。クライアントはこの Cookie の値を読み取り、カスタムリクエストヘッダー（例：X-CSRF-Token）として含めます。サーバーはヘッダーの値が Cookie の値と一致することを検証します。攻撃者は別のオリジンの Cookie を読み取れないため、正しいヘッダーを設定できません。

Synchronizer Token パターンでは、サーバー上でユーザーセッションごとに一意の CSRF トークンを生成します。HTML フォームでは、トークンを hidden フィールドに埋め込みます。SPA の API 呼び出しでは、エンドポイントまたは meta タグを介してトークンを提供し、カスタムヘッダーで送信します。サーバーは状態を変更するすべてのリクエストでトークンを検証します。

JWT をメモリまたは localStorage に保存し、Authorization: Bearer ヘッダーで送信する React SPA は、従来型の CSRF に対して脆弱ではありません。CSRF 攻撃は Cookie ベースの認証を悪用します。攻撃者のページは、CORS の制限によりクロスオリジンリクエストにカスタムヘッダーを設定できないため、Authorization ヘッダーを偽造できません。

単純なクロスオリジンリクエスト（フォーム POST や画像の読み込み）では、カスタムヘッダーを使用できません。カスタムヘッダーを含められるのは、CORS のプリフライトを通過するリクエストだけです。そして、プリフライトリクエストにはサーバーによる明示的な許可が必要です。すべての変更操作で X-Requested-With: XMLHttpRequest のようなカスタムヘッダーを要求する API は、単純な CSRF 攻撃から本質的に保護されます。

CORSは、クロスオリジンリクエストのレスポンスを読み取れるオリジンを制御します。CSRFは、状態を変更するリクエストを送信できるオリジンに関するものです。オリジンを制限するようにCORSを設定しても、CSRFは防げません。ブラウザーはリクエストとCookieを送信し、CORSが制御するのはレスポンスをJavaScriptから参照できるかどうかだけです。CSRF攻撃では、レスポンスを読み取る必要はありません。

セッションCookieには、HttpOnly: true（JavaScriptによるCookieの読み取りを防ぎ、XSSを利用したトークン窃取を阻止します）、Secure: true（HTTPS経由でのみ送信します）、SameSite: LaxまたはStrict（CSRFを防ぎます）、適切なMax-Ageまたは有効期限を設定してください。これら4つの属性を組み合わせることで、セッション管理のセキュリティを大幅に強化できます。

Next.js App Routerでは、Server ActionsにPOSTリクエストを使用します。Next.jsは、Originヘッダーとホストを照合してCSRF対策を実装しており、予期しないオリジンからのリクエストは拒否されます。この組み込みのチェックとSameSite=LaxのセッションCookieを組み合わせることで、Server Actionベースの変更処理に対する堅牢なCSRF対策になります。

クロスサイトのPOSTリクエストをブロックしつつ、クロスサイトのGETナビゲーションを許可するSameSite Cookieの値はどれですか？

CSRFは、ブラウザーをだまして認証済みのクロスサイトリクエストを送信させることで、Cookieベースの認証を悪用します。SameSite=Laxは、最新のブラウザーにおける基本的な防御策です。Double Submit CookieパターンとSynchronizer Tokenパターンによって、さらに保護を強化できます。AuthorizationヘッダーでJWTを使用するReact SPAは、本質的にCSRFに強い構成です。カスタムの必須ヘッダーやCORSのプリフライトもCSRFの緩和に役立ちます。セッションCookieには必ずHttpOnly + Secure + SameSiteを組み合わせてください。