Django の CSRF 対策の仕組みと csrf_token タグ

CSRF（Cross-Site Request Forgery）は、ユーザーが意図しないリクエストを別サイトから送信させる攻撃手法です。Django はこの攻撃をフレームワークレベルで防御しており、開発者は {% csrf_token %} をテンプレートに書くだけで対策が完了します。

CSRF 攻撃とは

CSRF 攻撃のシナリオを簡単に整理します。

ユーザー自身はボタンを押した覚えがないのに、ログイン済みのセッションを悪用されてしまうわけです。

Django の CSRF 防御の仕組み

Django は「トークンベース」の防御を採用しています。仕組みは次のとおりです。

フォームを表示するとき、Django はランダムなトークン（CSRF トークン）を生成し、フォームの hidden フィールドとクッキーの両方に埋め込みます。POST リクエストを受け取ったとき、Django はフォームから送信されたトークンとクッキーのトークンを比較し、一致しなければ 403 エラーを返します。

攻撃者はユーザーのクッキーを読み取れないため、正しいトークンをフォームに埋め込むことができません。これにより、外部サイトからの不正なリクエストがブロックされます。

csrf_token タグの使い方

テンプレートの <form> タグ内に {% csrf_token %} を記述するだけで、hidden フィールドが自動生成されます。

<form method="post">
    {% csrf_token %}
    {{ form.as_p }}
    <button type="submit">送信</button>
</form>

レンダリングされた HTML を見ると、次のような hidden フィールドが挿入されていることがわかります。

<input type="hidden" name="csrfmiddlewaretoken"
       value="Ek8Qx7...（ランダムなトークン）">

この 1 行を忘れるだけで、POST リクエストはすべて 403 Forbidden になります。Django を使い始めた直後に最もよく遭遇するエラーの 1 つが、この {% csrf_token %} の書き忘れです。

CsrfViewMiddleware

CSRF 防御を担当しているのは django.middleware.csrf.CsrfViewMiddleware です。settings.py の MIDDLEWARE にデフォルトで含まれています。

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

このミドルウェアは以下のルールで動作します。

AJAX リクエストでの CSRF 対策

JavaScript から POST リクエストを送る場合は、クッキーからトークンを取得してリクエストヘッダーに含めます。

function getCookie(name) {
    const value = `; ${document.cookie}`;
    const parts = value.split(`; ${name}=`);
    if (parts.length === 2) return parts.pop().split(';').shift();
}

fetch('/api/articles/', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRFToken': getCookie('csrftoken')
    },
    body: JSON.stringify({ title: 'Hello' })
});

Django は X-CSRFToken ヘッダーも CSRF トークンとして受け入れます。フォームの hidden フィールドを使えない AJAX 通信では、この方法が標準的なアプローチになります。

csrf_exempt で特定のビューを除外する

外部 API からの Webhook 受信など、CSRF トークンを送れないケースでは @csrf_exempt デコレータで特定のビューだけ CSRF 検証を無効化できます。

from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def webhook(request):
    # 外部サービスからの POST を受け付ける
    ...

ただし、@csrf_exempt はそのビューの CSRF 防御を完全に無効化するため、代わりに API キーの検証やシグネチャの照合など、別の認証手段を必ず用意してください。

なぜ GET にはトークンが不要なのか

HTTP の仕様では、GET リクエストは「安全なメソッド」に分類されています。GET はデータの取得のみを行い、サーバーの状態を変更しないことが前提です。そのため Django は GET リクエストに対して CSRF 検証を行いません。

逆に言えば、GET リクエストでデータベースの変更や削除を行う設計は避けるべきです。「データを変更する操作は POST で」という HTTP の基本原則を守ることが、CSRF 対策の前提条件になっています。

CSRF 対策は Django が自動で処理してくれますが、その仕組みを理解しておくことで、403 エラーの原因特定や AJAX 通信での適切な対応が素早くできるようになります。