ホーム / セキュアコーディング /

CSRF対策の実装でWebアプリを守ろう！具体的なコード例と注意点

2025年4月29日火曜日

セキュアコーディング

Webサイトのセキュリティ対策、ちゃんとできていますか？

見落としがちな攻撃の一つにCSRF（クロスサイトリクエストフォージェリ）があります。今回は、Webアプリ開発者なら絶対に知っておきたいCSRF対策の実装について、初心者の方にも分かるように、実際のコード例を交えながら解説していきます。

この記事では、CSRF攻撃がどんなものか、なぜ対策が必要なのかという基本から、トークンを使った実際の対策コード、フレームワークでの簡単な実装方法、そして意外とハマりやすい注意点まで、幅広くカバーします。

ちょっと難しそう？いえいえ、大丈夫！一緒にセキュリティレベル、上げちゃいましょう！

この記事で学べること

  • CSRF攻撃の仕組みと怖さ
  • CSRF対策の基本的な考え方
  • トークンを使ったCSRF対策の詳しい実装手順
  • 主要なプログラミング言語やフレームワークでの対策方法
  • CSRF対策でよくあるミスや気をつけるべき点

CSRF対策の実装はなぜ重要？攻撃の仕組みと脅威を理解しよう

まず、CSRFって何？ってところから始めましょう。

CSRFは、Cross-Site Request Forgeries の略で、日本語だとクロスサイトリクエストフォージェリと呼ばれます。なんだか難しそうな名前ですよね。

簡単に言うと、悪意のある人が作った罠サイトなどを利用して、ログイン中のユーザーに意図しない操作（例えば、掲示板への書き込み、商品の購入、パスワード変更など）を強制的に行わせる攻撃のことです。

想像してみてください。あなたが普段使っているネットバンキングにログインしたまま、別のタブで怪しいサイトを見ていたとします。

その怪しいサイトに仕込まれた罠をクリック（あるいはページを開くだけで）してしまった結果、気づかないうちに誰かにお金が送金されていた…なんてことが起こりうるのがCSRF攻撃の怖さです。

攻撃者は、ユーザーがログインしている状態を利用します。正規のサイト側から見ると、あたかも本物のユーザーが操作しているように見えるため、不正なリクエストだと気づきにくいのです。

CSRF対策の実装は、こうした意図しない操作を防ぎ、ユーザーとサービスを守るために、Webアプリケーション開発において絶対に欠かせないセキュアコーディングの実践項目と言えるでしょう。

図：CSRF攻撃の流れ

【悪意のあるサイト】          【正規のサイト】            【ユーザーのブラウザ】
   (罠ページ表示) --------> (ユーザーがクリック) --+
       |                                         |
       +-------------------(意図しないリクエスト送信)--> (処理実行!)

CSRF対策の基本的な考え方

じゃあ、どうやってCSRF攻撃を防げばいいのでしょうか？

基本的な考え方はシンプルで、「そのリクエストが、本当にユーザー自身の意思で行われたものかを確認する仕組みを入れる」ことです。

悪意のあるサイトから送られてくるリクエストには、正規のユーザーからのリクエストであることを証明する「しるし」がありません。

一方、正規のサイトを経由したリクエストには、サイト側が付与した「しるし」を付けるようにします。サーバー側でその「しるし」を確認できれば、正規のリクエストだと判断できるわけです。

この「しるし」を実現する方法として、主に以下の３つがあります。

  • トークン（Synchronizer Token Pattern）を使う方法
    リクエストごとに秘密の文字列（トークン）を発行し、リクエスト時にそのトークンを検証します。最も一般的な方法です。
  • Double Submit Cookie を使う方法
    Cookie とリクエストパラメータの両方で秘密の値を送り、一致するか検証します。
  • SameSite Cookie 属性を利用する方法
    Cookie の属性で、別ドメインからのリクエスト時に Cookie を送らないようにブラウザに指示します。比較的新しい仕組みです。

今回は、最もよく使われるトークン方式を中心に、詳しい実装方法を見ていきましょう。

図：トークン方式の流れ

【正規のサイト】          【ユーザーのブラウザ】
   (フォーム表示時にトークン生成・埋込) ---> (フォーム表示)
                                         |
   (フォーム送信時にトークンも送信) <------- (ユーザーが送信)
       |
   (サーバーでトークン検証 OK!) --------> (処理実行)

最も一般的なトークンを用いたCSRF対策の実装

トークンを使ったCSRF対策は、以下のステップで実装します。なんだか秘密の合言葉を使うみたいで、ちょっとワクワクしませんか？

  1. トークンの生成
    ユーザーがフォームを表示する際など、サーバー側で推測困難なランダムな文字列（トークン）を生成します。
  2. トークンの埋め込み
    生成したトークンを、ユーザーのセッション情報などに保存すると同時に、HTMLフォームの中に hidden フィールド（画面には見えない入力欄）として埋め込みます。
  3. トークンの検証
    ユーザーがフォームを送信してきたら、サーバー側で、送信されてきた hidden フィールドの値と、セッションに保存しておいたトークンの値が一致するかどうかを確認します。一致すれば正規のリクエスト、一致しなければ不正なリクエストとして処理を中断します。

ポイントは、悪意のあるサイトは正規のトークンを知ることができない、という点です。ユーザーのセッションに保存されたトークンは、そのユーザーとサーバーの間だけの秘密情報だからです。

そのため、悪意のあるサイトから送られてくるリクエストには、正しいトークンが含まれていない（または含まれていても間違っている）ので、サーバー側で見破ることができるのです。

PHPでのCSRF対策実装例

それでは、PHPでトークン方式のCSRF対策を実装する簡単な例を見てみましょう。ここではセッションを使います。

まず、フォームを表示する側のPHP（例：`form.php`）です。

<?php
session_start();

// トークンを生成する関数 (推測困難なものを生成すること)
function generate_token() {
    // PHP 7 以降なら random_bytes を使うのが推奨
    if (function_exists('random_bytes')) {
        return bin2hex(random_bytes(32));
    } else {
        // 古いバージョンの場合 (より安全な方法を検討すべき)
        return bin2hex(openssl_random_pseudo_bytes(32));
    }
}

// セッションにトークンがない場合は生成して保存
if (!isset($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = generate_token();
}
$token = $_SESSION['csrf_token'];
?>

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>CSRF対策フォーム</title>
</head>
<body>
    <h1>何かを投稿するフォーム</h1>
    <form action="submit.php" method="post">
        <!-- ここでトークンを hidden フィールドに埋め込む -->
        <input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($token, ENT_QUOTES, 'UTF-8'); ?>">
        
        <label for="message">メッセージ:</label><br>
        <textarea id="message" name="message" rows="4" cols="50"></textarea><br><br>
        
        <input type="submit" value="投稿する">
    </form>
</body>
</html>

次に、フォームの送信先となるPHP（例：`submit.php`）です。ここでトークンを検証します。

<?php
session_start();

// 送信されてきたトークンとセッション内のトークンを比較検証する関数
function validate_token($request_token) {
    if (!isset($_SESSION['csrf_token']) || !isset($request_token)) {
        return false; // トークンが存在しない
    }
    // タイミング攻撃対策として hash_equals を使うのが推奨
    return hash_equals($_SESSION['csrf_token'], $request_token);
}

// POSTリクエストかどうかを確認 (必須ではないが、状態変更はPOSTが基本)
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    die('不正なリクエストです。');
}

// 送信されたトークンを取得
$submitted_token = isset($_POST['csrf_token']) ? $_POST['csrf_token'] : '';

// トークンを検証
if (!validate_token($submitted_token)) {
    // トークンが無効なら処理を中断
    die('CSRFトークンが無効です。フォームを再読み込みしてもう一度お試しください。');
}

// トークンが有効なら、ここで実際の処理を行う
$message = isset($_POST['message']) ? $_POST['message'] : '';
echo "<h1>投稿を受け付けました！</h1>";
echo "<p>メッセージ: " . htmlspecialchars($message, ENT_QUOTES, 'UTF-8') . "</p>";

// 処理が完了したら、念のためセッションのトークンを削除または再生成するのも良い
unset($_SESSION['csrf_token']); // または再生成: $_SESSION['csrf_token'] = generate_token();

?>

このコードは簡単な例ですが、基本的な流れは掴めるはずです。ポイントは、`form.php`で生成・埋め込みしたトークンを、`submit.php`でセッションの値と比較している点です。

もしトークンが一致しなければ、処理を中断してエラーメッセージを表示します。セキュアコーディングの観点からは、トークン生成には暗号学的に安全な乱数生成器（`random_bytes`など）を使い、比較には`hash_equals`関数を使うことが推奨されます。

Python(Flask/Django)でのCSRF対策実装例

PythonのWebフレームワーク、FlaskやDjangoを使うと、CSRF対策はもっと簡単になります！多くの場合、フレームワークが面倒な部分を肩代わりしてくれるからです。

Flaskの場合
Flask自体にはCSRF保護機能は組み込まれていませんが、拡張機能の`Flask-WTF`（または`Flask-SeaSurf`）を使うのが一般的です。

`Flask-WTF`を使う場合、以下のように設定し、WTFormsを使ってフォームを定義します。

# Flaskアプリの設定ファイルや初期化部分
from flask import Flask, render_template, request, flash, redirect, url_for
from flask_wtf.csrf import CSRFProtect
# WTForms を使う場合
from flask_wtf import FlaskForm
from wtforms import StringField, SubmitField, HiddenField
from wtforms.validators import DataRequired

app = Flask(__name__)
# 必ず秘密鍵を設定してください！
app.config['SECRET_KEY'] = 'your-secret-key' # 実際には環境変数などから読み込むべき
csrf = CSRFProtect(app)

# WTFormsを使ったフォーム定義
class MyForm(FlaskForm):
    message = StringField('メッセージ', validators=[DataRequired()])
    # csrf_token フィールドは自動で追加されるか、明示的に書いてもOK
    # csrf_token = HiddenField() # Flask-WTF 0.14.x 以前は明示的に書く必要があった
    submit = SubmitField('送信')

@app.route('/', methods=['GET', 'POST'])
def index():
    form = MyForm()
    if form.validate_on_submit():
        # CSRF検証は validate_on_submit() 内で自動的に行われる
        message = form.message.data
        flash(f'メッセージ「{message}」を受け取りました！')
        return redirect(url_for('index'))
    # GETリクエスト時やバリデーション失敗時
    return render_template('form_flask.html', form=form)

if __name__ == '__main__':
    app.run(debug=True)

テンプレート側（`form_flask.html`）では、フォームタグ内に`{{ form.csrf_token }}`（または`{{ form.hidden_tag() }}`）を含めるだけでOKです。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Flask CSRF Form</title>
</head>
<body>
    <h1>Flaskフォーム</h1>
    {% with messages = get_flashed_messages() %}
      {% if messages %}
        <ul>
        {% for message in messages %}
          <li>{{ message }}</li>
        {% endfor %}
        </ul>
      {% endif %}
    {% endwith %}

    <form method="POST" action="">
        {{ form.hidden_tag() }} {# これが csrf_token を含む隠しフィールドをレンダリングする #}
        <p>
            {{ form.message.label }}<br>
            {{ form.message(size=30) }}
            {% if form.message.errors %}
                <ul>
                {% for error in form.message.errors %}
                    <li style="color: red;">{{ error }}</li>
                {% endfor %}
                </ul>
            {% endif %}
        </p>
        <p>{{ form.submit() }}</p>
    </form>
</body>
</html>

Djangoの場合
Djangoは、デフォルトでCSRFミドルウェア（`django.middleware.csrf.CsrfViewMiddleware`）が有効になっており、非常に強力なCSRF保護機能が組み込まれています。

特別な設定はほとんど不要です。
テンプレート内の`<form>`タグの中に`{% csrf_token %}`というテンプレートタグを記述するだけで、自動的にトークンが埋め込まれ、POSTリクエスト時に検証が行われます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Django CSRF Form</title>
</head>
<body>
    <h1>Djangoフォーム</h1>
    <form method="post">
        {% csrf_token %} {# これだけでOK！ #}
        {{ form.as_p }} {# Djangoフォームオブジェクトを使っている場合 #}
        <button type="submit">送信</button>
    </form>
</body>
</html>

このように、フレームワークを使うとCSRF対策の実装がかなり楽になりますね！ただし、フレームワークが何をしてくれているのかを理解しておくことは、後述する注意点を避けるためにも必要です。

Ruby(Rails)でのCSRF対策実装例

Ruby on Railsを使っている場合も、CSRF対策はフレームワークがしっかりサポートしてくれています。

Railsでは、`app/controllers/application_controller.rb`にデフォルトで`protect_from_forgery with: :exception`という記述があります。これだけで、ほとんどのPOST、PUT、DELETE、PATCHリクエストに対してCSRF保護が自動的に有効になります。

Railsのフォームヘルパー（`form_with`や`form_tag`など）を使うと、自動的にCSRFトークンを含む隠しフィールドがHTMLに追加されます。

手動でフォームを書く場合でも、`form_authenticity_token`ヘルパーメソッドを使ってトークンを取得し、`authenticity_token`という名前のパラメータとして送信する必要があります。

また、JavaScriptからの非同期リクエスト（Ajaxなど）を行う場合は、リクエストヘッダーに`X-CSRF-Token`としてトークンを含める必要があります。Railsは、`rails-ujs`（またはそれ以前の`jquery-ujs`）を通じて、ヘッダーに自動でトークンを設定する仕組みを提供しています。

<!-- Railsのビュー (erb) で form_with を使った例 -->
<%= form_with(model: @article, local: true) do |form| %>
  <!-- form_with が自動で authenticity_token フィールドを追加してくれる -->
  <div>
    <%= form.label :title %><br>
    <%= form.text_field :title %>
  </div>

  <div>
    <%= form.label :body %><br>
    <%= form.text_area :body %>
  </div>

  <div>
    <%= form.submit %>
  </div>
<% end %>

<!-- 生成されるHTML（一部抜粋） -->
<input type="hidden" name="authenticity_token" value="[ここに実際のトークンが入る]">

Railsの「設定より規約」の考え方により、開発者はCSRF対策をあまり意識しなくても、基本的な保護が受けられるようになっています。便利ですね！

その他の言語・フレームワークでのCSRF対策実装の考え方

PHP, Python, Ruby 以外の言語やフレームワーク（例えば Java の Spring Framework, Node.js の Express など）を使っていても、CSRF対策の基本的な考え方は同じです。つまり、推測困難なトークンを生成し、リクエスト時に検証する、という流れです。

多くのモダンなWebフレームワークには、標準でCSRF保護機能が組み込まれていたり、信頼できるライブラリやミドルウェアが提供されています。

まずは、お使いのフレームワークの公式ドキュメントを確認し、推奨されるCSRF対策の方法を調べてみましょう。
「（フレームワーク名） CSRF 対策」のようなキーワードで検索すれば、情報が見つかるはずです。

もしフレームワークを使っていなかったり、自前で実装する必要がある場合でも、PHPの例で見たようなトークンの生成・埋め込み・検証のステップを参考にすれば、実装できるはずです。その際は、必ず暗号学的に安全な乱数生成器を使用してくださいね。

意外と知らない？CSRF対策実装の落とし穴と注意点

よし、これでCSRF対策はバッチリ！…と思いたいところですが、実装にはいくつか気をつけたい落とし穴があります。

せっかく対策しても、やり方が間違っていると効果がなかったり、別の問題を引き起こしたりすることもあるんです。セキュアコーディングは、ただ実装するだけでなく、正しく理解して使うことが肝心です。

トークンは推測困難なものにする

これは基本中の基本ですが、意外と見落としがちです。

CSRFトークンは、攻撃者に推測されてしまうと意味がありません。例えば、ユーザーIDやタイムスタンプなど、簡単に予測できる値を使うのは絶対にNGです。

必ず、暗号学的に安全な乱数生成器（CSPRNG: Cryptographically Secure Pseudo-Random Number Generator）を使って、十分に長い（例：32バイト以上）ランダムな文字列を生成しましょう。

PHPなら`random_bytes()`、Pythonなら`secrets`モジュール、Rubyなら`SecureRandom`モジュールなどが推奨されます。

// PHPでの安全なトークン生成例
$token = bin2hex(random_bytes(32)); 

# Pythonでの安全なトークン生成例
import secrets
token = secrets.token_hex(32)

# Rubyでの安全なトークン生成例
require 'securerandom'
token = SecureRandom.hex(32)

単純な`rand()`関数や、現在時刻を元にしただけの値などは、安全ではありません。

GETリクエストへの安易な状態変更処理は避ける

Webの基本として、GETリクエストは情報の取得（Read）、POSTリクエストは情報の作成・更新・削除（Create/Update/Delete）に使うのが原則です。

もし、GETリクエストを受け付けるURL（例えば `/delete?id=123`のようなリンク）で、データの削除などの状態を変更する処理を実装してしまうと、CSRF攻撃が非常に簡単になってしまいます。

悪意のあるサイトに、そのURLへのリンクや画像タグを埋め込むだけで、ユーザーがページを開いただけで意図しない処理が実行されてしまう可能性があるのです。

状態を変更する操作は、必ずPOSTリクエスト（またはPUT, DELETEなど適切なメソッド）で行い、その上でCSRFトークンの検証を行うようにしましょう。

// これはダメな例（GETで削除処理）
app.get('/delete_item', (req, res) => {
  const itemId = req.query.id;
  // ... itemId を使ってデータベースから削除する処理 ...
  res.send('アイテムを削除しました（危険！）');
});

// こうすべき（POSTで削除処理 + CSRFトークン検証）
app.post('/delete_item', validateCsrfToken, (req, res) => { // validateCsrfTokenは自作のミドルウェアなど
  const itemId = req.body.id; 
  // ... itemId を使ってデータベースから削除する処理 ...
  res.send('アイテムを削除しました（安全）');
});

フレームワークの保護機能に頼りすぎない

Flask, Django, Railsなどのフレームワークが提供するCSRF保護機能は非常に強力で便利です。しかし、それに完全に頼りきってしまうのは少し危険かもしれません。

例えば、設定が間違っていて実は保護が有効になっていなかったり、Ajax通信など特定のケースで別途対応が必要なのに気づかなかったりする可能性があります。

フレームワークが内部でどのような仕組み（多くはトークン方式）でCSRFを防いでいるのか、基本的な原理だけでも理解しておくことが、いざという時に役立ちます。ドキュメントを読んで、正しく設定・利用できているかを確認する習慣をつけましょう。

SameSite Cookie属性による緩和策

最近のブラウザでは、Cookieに`SameSite`属性というものを設定できます。

`SameSite`属性は、異なるドメインからのリクエスト（クロスサイトリクエスト）が発生したときに、Cookieを送信するかどうかを制御するためのものです。

以下の３つの値があります。

  • Strict
    異なるドメインからの全てのリクエストでCookieを送信しません。最も安全ですが、別サイトからリンクで飛んできた直後などにログイン状態が維持されない場合があります。
  • Lax
    一部の安全なトップレベルナビゲーション（リンククリックなど）ではCookieを送信しますが、POSTリクエストやiframe、Ajaxなどでは送信しません。多くの場合、セキュリティと利便性のバランスが良いとされています。これが多くのブラウザのデフォルトになりつつあります。
  • None
    従来通り、全てのクロスサイトリクエストでCookieを送信します。ただし、`None`を設定する場合は、同時に`Secure`属性（HTTPS通信時のみCookieを送信する）も必須となります。

`SameSite=Lax`または`Strict`を設定することで、多くのCSRF攻撃をブラウザレベルで緩和できます。

しかし、全てのブラウザが対応しているわけではなかったり、特定の状況下（例：古いブラウザ、一部のGETリクエストによる攻撃）では防げない可能性もあるため、あくまで補助的な対策と考えるべきです。トークン方式などのサーバーサイドでの対策と併用するのが最も確実な方法と言えます。

【まとめ】安全なWebサイトのためのCSRF対策実装を習慣に

今回は、CSRF対策の実装について、その仕組みから具体的なコード例、注意点までを見てきました。ちょっと盛りだくさんでしたかね？

最後に、この記事のポイントをまとめておきましょう。

  • CSRFはユーザーに意図しない操作をさせる攻撃。対策は必須です。
  • 基本的な対策は「リクエストが正規ユーザーのものか確認する」こと。トークン方式が一般的。
  • トークンは推測困難なものを生成し、フォームに埋め込み、サーバーで検証する流れを実装。
  • フレームワークを使えば実装は楽になるが、仕組みの理解も必要。
  • GETリクエストで状態変更しない、SameSite属性も活用するなど、注意点を守って正しく実装しましょう。

CSRF対策の実装は、安全なWebサービスを提供する上で、開発者が身につけておくべき基本的なスキルの一つです。

難しく考えすぎず、まずは今回学んだことを参考に、ご自身のコードを見直したり、新しいプロジェクトで実践してみてください。

セキュアコーディングを意識することが、ユーザーとあなたのサービスを守る第一歩になります。自信を持って、安全なWebアプリケーション開発を進めていきましょう！

このブログを検索
  • ()

自己紹介

自分の写真
リモートワークでエンジニア兼Webディレクターとして活動しています。プログラミングやAIなど、日々の業務や学びの中で得た知識や気づきをわかりやすく発信し、これからITスキルを身につけたい人にも役立つ情報をお届けします。 note → https://note.com/yurufuri X → https://x.com/mnao111

QooQ