先生と生徒の会話形式で理解しよう

生徒

「Railsでログインや投稿ができるのは便利だけど、セキュリティ的に大丈夫なんですか？」

先生

「そこはとても大事な視点だね。RailsではCSRF対策という仕組みで、安全にリクエストを処理しているんだよ。」

生徒

「CSRFって何ですか？初心者でもわかるように説明してもらえますか？」

先生

「もちろん！CSRF対策の仕組みとRailsでの設定方法、APIモードでの扱いまで順番に説明していくね。」

1. CSRFとは？

CSRF（シーエスアールエフ）とは、「クロスサイトリクエストフォージェリ（Cross-Site Request Forgery）」の略で、悪意あるサイトから知らない間にリクエストが送られる攻撃のことです。

たとえば、ログインしたままの状態で、別の悪質なサイトを開いたときに勝手に投稿されたり削除されたりする可能性があります。

これを防ぐために、Railsでは自動で本人しか送れない秘密のトークンをチェックする仕組みが用意されています。

2. RailsのCSRF対策：protect_from_forgeryとは？

Railsのコントローラでは、デフォルトでprotect_from_forgeryというフィルターが有効になっており、CSRFトークンの確認が行われます。

これはApplicationControllerで自動的に呼び出されています。


class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception
end

with: :exceptionという指定により、CSRFトークンが一致しない場合は処理を中断し、例外を発生させます。

3. CSRFトークンって何？

CSRFトークンとは、「これは本人のリクエストですよ」という印（しるし）のようなもので、フォーム送信ごとに自動で付与されます。

Railsではフォームを作成するヘルパー（form_withやform_for）を使うと、トークンが自動で埋め込まれます。


<form action="/posts" method="post">
  <input type="hidden" name="authenticity_token" value="秘密のトークン">
  <!-- 他の入力フィールド -->
</form>

このトークンが一致していなければ、Railsはそのリクエストを拒否します。

4. APIモードの場合のCSRF対策

RailsにはAPI専用モード（--apiオプション）があり、画面表示をせずにデータのやりとりだけを行う構成です。このときは通常のHTMLフォームではなく、JavaScriptや他のアプリからのリクエストになることが多いため、CSRF保護は最初から無効になっています。

つまり、APIモードではprotect_from_forgeryが使われていません。

その代わりに、トークンベースの認証（例：JWTやAPIキー）で不正アクセスを防ぎます。

5. APIでCSRFエラーが出るときの対処法

APIとして動かしているつもりなのに、CSRFトークンが原因でエラーが出る場合は、次のように対応することがあります。


class Api::BaseController < ActionController::API
  include ActionController::RequestForgeryProtection
  protect_from_forgery with: :null_session
end

with: :null_sessionにすることで、トークンが一致しない場合でもセッションを破棄し、処理自体は通すようになります。ただし、セキュリティ的には注意が必要です。

6. 開発中に確認したい！CSRFトークンの見方

ブラウザでフォームのHTMLを確認すれば、authenticity_tokenという名前のhiddenフィールドが入っているのがわかります。

Google Chromeで「右クリック → 検証」
「Elements」タブでformタグ内のinputを確認

Railsが自動で生成してくれているので、初心者は深く考えなくてもOKですが、「なぜ必要なのか」を理解しておくと安心です。

7. CSRF対策を無効にする場合の注意点

どうしてもCSRF対策を一時的に外したい場合、次のようにskip_before_actionで無効化できます。


skip_before_action :verify_authenticity_token

ただし、セキュリティ上とても危険なので、本番環境では絶対に避けるべきです。外部APIとの連携時など、限定的な場面でのみ使用します。

8. RailsがCSRFを自動で守ってくれる仕組み

Railsのすごいところは、開発者が意識しなくても多くのセキュリティ対策が自動で効いていることです。

form_withやform_forを使っていれば、トークンの設定は自動で行われ、protect_from_forgeryもデフォルトで有効です。

つまり、基本的には「Railsに任せておけば安心」という設計になっているのです。

まとめ

RailsのCSRF対策を理解すると「安全な仕組み」が見えてくる

ここまでの記事では、RailsにおけるCSRF対策について、基本的な考え方から具体的な実装方法、さらにAPIモードとの違いまでを順を追って解説してきました。RailsでWebアプリケーションを作成するうえで、セキュリティは後回しにされがちですが、CSRFは初心者の段階から必ず理解しておきたい重要なテーマのひとつです。

CSRFとは、ユーザーが気づかないうちに、第三者の悪意あるサイトからリクエストを送られてしまう攻撃です。ログイン状態が維持されていることを悪用され、投稿や削除、設定変更などが勝手に実行されてしまう可能性があります。このような攻撃は、見た目では気づきにくく、被害が出てから問題になることも少なくありません。

Railsでは、このCSRF攻撃を防ぐためにprotect_from_forgeryという仕組みが標準で組み込まれています。ApplicationControllerで特別な設定をしなくても、自動的にCSRFトークンの検証が行われるため、Railsの通常のWebアプリケーションでは、開発者が細かく意識しなくても一定レベルの安全性が確保されています。

CSRF対策の中心となるのがCSRFトークンです。このトークンは、フォーム送信時にhiddenフィールドとして自動的に埋め込まれ、サーバー側で一致するかどうかを検証されます。正しい画面から送信されたリクエストでなければトークンが一致しないため、不正なリクエストを確実にブロックできます。form_withやform_forといったRailsのヘルパーを使うことで、この仕組みは自然に利用できます。

一方で、RailsのAPIモードでは考え方が少し変わります。APIモードではHTMLフォームを使わず、JavaScriptや外部アプリからの通信が中心になるため、CSRFトークンによる保護はデフォルトで無効になっています。その代わりに、JWTやAPIキーなどのトークン認証によって安全性を確保するのが一般的です。この違いを理解していないと、「なぜAPIではCSRFエラーが出ないのか」「なぜ通常のRailsでは必要なのか」と混乱しやすくなります。

APIとしてRailsを利用している場合でも、コントローラの構成によってはCSRF対策が有効になってしまい、意図せずエラーが発生することがあります。その際にはwith: :null_sessionの指定などで挙動を調整できますが、安易にCSRF対策を無効化するのは危険です。どのリクエストが信頼できるのかを明確にし、用途に応じた対策を選ぶことが重要です。

Railsは「安全なデフォルト」を重視したフレームワークです。CSRF対策もその代表例であり、正しく使えば強力な味方になります。逆に、仕組みを理解しないまま無効化してしまうと、重大なセキュリティリスクを抱えることになります。初心者のうちから、なぜRailsがこのような仕組みを用意しているのかを意識しておくことで、より信頼性の高いアプリケーションを作れるようになります。

CSRF対策の確認用サンプルプログラム


class PostsController < ApplicationController
  protect_from_forgery with: :exception

  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to @post
    else
      render :new
    end
  end
end

このように、通常のRailsコントローラでは特別な処理を書かなくてもCSRF対策が有効になります。Railsの流儀に沿ってコードを書くことが、そのままセキュリティ対策につながっている点も、大きな特徴です。

先生と生徒の振り返り会話

生徒

「CSRFって難しそうだと思っていましたが、仕組みを知ると意外とシンプルですね。」

先生

「そうですね。Railsが多くの部分を自動で守ってくれているんです。」

生徒

「form_withを使うだけでトークンが入るのは安心感があります。」

先生

「その通りです。Railsのレールに乗る、という考え方ですね。」

生徒

「APIモードでは考え方が違うのも、ようやく理解できました。」