RailsのCSRF対策を完全解説!authenticity_token・SameSite・APIモードまで初心者向けに理解
生徒
「Railsでフォームを送信するとき、セキュリティ対策って何か必要なんですか?」
先生
「Railsでは最初からCSRFという攻撃を防ぐ仕組みが組み込まれています。」
生徒
「CSRFって何ですか?聞いたことがなくて…」
先生
「では、仕組みと一緒に、authenticity_tokenやCookieの話も順番に見ていきましょう。」
1. Railsとセキュリティ対策の関係
Railsは、Webアプリケーションを安全に作るためのセキュリティ対策が最初から用意されています。その代表例がCSRF対策です。CSRFとは、利用者が気付かないうちに、意図しない操作を実行させられてしまう攻撃のことです。Railsでは「正しい画面から送られた操作かどうか」をチェックすることで、不正なリクエストを防いでいます。
Railsの仕組みを根本から理解し、現場で通用する 「設計のセオリー」を身につけたいならこの一冊。 MVC、テスト、Docker対応など、実践的な内容が凝縮されています。
パーフェクト Ruby on RailsをAmazonで見る※ Amazon広告リンク
2. CSRF(クロスサイトリクエストフォージェリ)とは?
CSRFは、とてもシンプルに言うと「なりすまし操作」です。例えば、ログイン中の状態で別の怪しいサイトを開くと、そのサイトから勝手にデータ更新の指示が送られてしまうことがあります。本人は何もしていないのに、サーバー側は「正規の操作」だと勘違いしてしまいます。Railsでは、このような攻撃を防ぐために、特別な合言葉を使います。
3. authenticity_tokenの仕組み
Railsでは、この合言葉をauthenticity_tokenと呼びます。フォーム画面を表示するときに、ランダムな文字列を一緒に埋め込み、送信時に一致するかを確認します。一致しなければ、不正な操作として拒否されます。
<form action="/posts" method="post">
<input type="hidden" name="authenticity_token" value="ランダムな文字列">
<input type="text" name="title">
<input type="submit">
</form>
4. コントローラでのCSRFチェック
Railsのコントローラでは、CSRF対策が自動で有効になります。これを行っているのがprotect_from_forgeryです。通常は自分で書く必要はありませんが、内部ではこの処理が動いています。
class ApplicationController < ActionController::Base
protect_from_forgery with: :exception
end
これにより、tokenが一致しないリクエストはエラーになります。
5. SameSite属性とCookieの関係
CSRF対策ではCookieも重要です。RailsではCookieにSameSiteという設定を付けています。これは「別のサイトからのアクセス時にCookieを送るかどうか」を制御する仕組みです。SameSiteを有効にすることで、怪しいサイトからのリクエストにCookieが付かなくなり、攻撃を防ぎやすくなります。
Rails.application.config.session_store :cookie_store,
key: '_sample_app_session',
same_site: :lax
6. APIモードでのCSRF対策
RailsにはAPI専用のモードがあります。APIモードでは、画面フォームを使わないため、authenticity_tokenを使わない構成が一般的です。その代わり、トークン認証など別の方法で安全性を確保します。APIモードでは、CSRFチェックを無効にするケースもあります。
class ApplicationController < ActionController::API
end
7. Strong Parametersとの関係
Strong Parametersは、送信されるデータの中身を制限する仕組みです。CSRFが「誰から送られたか」を守るのに対し、Strong Parametersは「何を送ってよいか」を守ります。両方を組み合わせることで、安全なRailsアプリになります。
def post_params
params.require(:post).permit(:title, :body)
end
8. CSRF対策を無効にする場合の注意点
開発中やAPI用途でCSRF対策を外すこともありますが、理由を理解せずに無効にするのは危険です。意図しない更新や削除が起きる可能性があります。Railsが用意している仕組みは、基本的に有効のまま使うのが安全です。