今回はRailsでAPIを叩いた際に発生した「ActionController::InvalidAuthenticityToken」の解決方法とその原因についてまとめました。APIを叩くツールとしてはTalend API Testerを用いています。

エラー概要
Talend API Testerを用いてPATCHメソッドでAPIを叩くと「422 Unprocessable Entity」エラーが発生してしまいます。


ターミナルのログを見てみると「ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken)」が吐かれています。
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
解決方法
このエラーを解決するには、aplication.controller.rbにprotect_from_forgeryメソッドを追記しましょう。この1行を追加するだけで解決します。
class ApplicationController < ActionController::Base
protect_from_forgery
end
protect_from_forgeryメソッドとは
protect_from_forgeryメソッドは、CSRF(Cross-Site Request Forgery, クロスサイトリクエストフォージェリー)対策で用いられるメソッドです。
CSRF(Cross-Site Request Forgery)を簡単に説明すると、悪意のあるユーザーがサーバーへのリクエストを捏造して正当なものに見せかけ、認証済みユーザーを装うという攻撃手法です。Railsでは、一意のトークンを生成して送信のたびに真正性を確認することでこの種の攻撃から保護します。
定番のCSRF対策としては認証用トークンをアプリケーション内に差し込むということをし、そのアプリケーションが正当かどうかを判別します。しかしRailsではありがたいことに、protect_from_forgeryメソッドを追記するだけでCSRF対策を行ってくれます。
今回はprotect_from_forgeryメソッドが定義されていなかったため、外部からPOSTしようとした際にエラーが出たという流れになります。
まとめ
- ActionController::InvalidAuthenticityTokenの解決方法としては、application.rbにprotect_from_forgeryの1行を追記する
- protect_from_forgeryメソッドは、CSRF(Cross-Site Request Forgery, クロスサイトリクエストフォージェリー)対策で用いられるメソッド
- CSRFは、悪意のあるユーザーがサーバーへのリクエストを捏造して正当なものに見せかけ、認証済みユーザーを装うという攻撃手法
参考
今回はRailsでAPIを叩いた際に発生する「ActionController::InvalidAuthenticityToken」の対処法について解説しました。CSRFは非常に重大なセキュリティ問題であるとRailsガイドで表記されているため、protect_from_forgeryメソッドは不要に削除しない方が良さそうです。
CSRFは、CVE (Common Vulnerabilities and Exposures) で報告されることはめったにありません (2006年でも0.1%以下) が、それでもGrossmanが言うところの「眠れる巨人」であり、危険なことに変わりはありません。筆者や他のセキュリティ専門家によるセキュリティ関連の実績に登場することはほとんどありませんが、CSRFは非常に重大なセキュリティ問題であることは強く認識していただきたいと思います。