0Pricing
Frontend Academy · レッスン

CSRF：SameSite Cookieとトークン

Cross-Site Request ForgeryがCookieを悪用する仕組みを理解し、SameSite=Strict/Laxで防止して、追加の保護として同期トークンを導入します。

「CSRF：SameSite Cookieとトークン」はCoddyKit上の無料Frontend Academyレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはFrontend Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Frontend Academyコースには全4レッスンが含まれています。

CSRFとは

クロスサイトリクエストフォージェリ：攻撃者が認証済みユーザーのブラウザをだまして、あなたのサイトにリクエストを送信させる攻撃です。ブラウザはユーザーのCookieを付加するため、サーバーは正規のユーザーからのリクエストだと判断します。

典型的なCSRF攻撃

ユーザーがbank.comにログインしています。そのユーザーがevil.comにアクセスします。evil.comは、攻撃者の口座番号を指定したbank.com/transferへの隠しフォームを送信します。ブラウザはbank.comのセッションCookieを自動的に送信します。サーバーは送金を実行します。

信頼の問題

CSRFが成立するのは、ブラウザが異なるオリジンへのリクエストにもCookieを自動的に含めるためです。追加の保護がなければ、サーバーはそのリクエストが悪意のあるサイトから送られたものかどうかを判別できません。

SameSite Cookie — 最新の対策

SameSite Cookie属性は、異なるオリジンへのリクエストでCookieを送信するタイミングを制御します。Strict：異なるオリジンには一切送信しません。Lax（Chromeのデフォルト）：トップレベルのGETナビゲーションの場合にのみ送信します。None：常に送信します（Secureも必須です）。

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax

SameSite=Laxのデフォルト

Chromeでは、SameSiteが指定されていない場合、すべてのCookieのデフォルトがLaxになります。これによりほとんどのCSRFを防げますが、明示的に指定することをおすすめします。

最大限のセキュリティにはSameSite=Strict

最も機密性の高いCookie（管理者セッションや銀行取引など）にはStrictを使用します。欠点は、別のサイトのリンクからアクセスしたユーザーがログアウトしたように見えることです。

CSRFトークン（Synchroniserパターン）

古いブラウザへの対応や、さらに安全性を高めるにはCSRFトークンを使用します。サーバーがランダムなトークンを生成してページに埋め込み、状態を変更するすべてのリクエストにそのトークンを要求します。

// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">

// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': token },
  body: JSON.stringify({ amount: 100 })
});

// Server verifies the X-CSRF-Token header matches the user's session

Double-Submit Cookie

サーバーがCSRF Cookieを設定します（JSから読み取れるようにHttpOnlyにはしません）。クライアントはその値を読み取り、ヘッダーで送信します。サーバーはCookieとヘッダーの値が一致することを確認します。攻撃者は異なるオリジンからCookieを読み取れないため、ヘッダーを再現できません。

なぜ機能するのか

攻撃者のevil.comは、bank.comのCookieを読み取れません（Same-Origin Policy）。そのため、X-CSRF-Tokenヘッダーを設定できません。リクエストはサーバー上のトークン検証に失敗します。

Bearerトークンを使用するSPAのCSRF

メモリ内に保存したAuthorization: Bearer <jwt>（Cookieではない）で認証する場合、CSRFは適用されません。ブラウザはヘッダーを自動送信しないためです。その一方で、XSSにはより脆弱になります（JavaScriptからアクセスできるトークンを盗まれる可能性があるためです）。

カスタムヘッダーの仕組み

カスタムヘッダー（例：X-Requested-With）付きのJSONのみを受け付けるAPIでは、ブラウザがプリフライトOPTIONSリクエストを送信します。プリフライトではCookieを含めないため、単純なフォームによるCSRFを事実上ブロックできます。

冪等エンドポイントと状態変更エンドポイント

CSRFは主に状態を変更するリクエスト（POST、PUT、DELETE）に影響します。GETエンドポイントは副作用のない冪等な処理にするべきです。そうすれば、偽造されたGETによって被害が発生することはありません。

確認問題

現代のブラウザで、デフォルトではほとんどのクロスサイトリクエストへのCookie送信を防ぐSameSite Cookieの値はどれでしょうか。

まとめ：CSRFの防止

セッションCookieにSameSite=Lax（またはStrict）を設定して、ほとんどのCSRFをブロックします。HttpOnlyとSecureも追加します。さらに保護するには、CSRFトークン（SynchroniserパターンまたはDouble-Submit Cookie）を使用します。ヘッダー内のBearerトークンはCSRFを回避できますが、XSSのリスクが高まります。カスタムヘッダーの仕組みにより、プリフライトを強制できます。GETは冪等にします。

よくある質問

「CSRF：SameSite Cookieとトークン」レッスンは無料ですか？

はい。「CSRF：SameSite Cookieとトークン」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Frontend Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Frontend Academyコースには全4レッスンが含まれています。

「CSRF：SameSite Cookieとトークン」で何を学びますか？

Cross-Site Request ForgeryがCookieを悪用する仕組みを理解し、SameSite=Strict/Laxで防止して、追加の保護として同期トークンを導入します。 ブラウザで直接実行するハンズオンコードでFrontend Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Frontend Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFrontend Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。

「CSRF：SameSite Cookieとトークン」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFrontend Academyレッスンでコードを書いて実行できますか？

はい。すべてのFrontend Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. XSS対策：出力エンコーディングとCSP
  2. CSRF：SameSite Cookieとトークン
  3. Content Security Policy：nonceとhash
  4. フロントエンドからのOAuthフロー
← Frontend Academyに戻る