Railsアプリケーションに対して、外からPOST送信しようとすると、422エラー・Can't verify CSRF token authenticityエラーが出ます。
これはRailsが自動で生成してくれるCSRF対策によるものらしく、よくわかっていなかったのでまとめてみました。

CSRFとは

CSRF（クロスサイトリクエストフォージェリ）は攻撃の一種なのですが、簡単に説明すると「攻撃者がターゲットに、自分で自分を攻撃させる攻撃」です。

もうちょっと詳しく言うと、「自分がログインしている（常時ログインなどで）サービスへ、知らぬ間にリクエストを送らされる攻撃」です。

通常、常時ログインなどでは、cookieにセッション情報が格納されますが、Railsではリクエストのたびにcookieを自動的に取得します。

そして、これこそがCSRFがつけいるセキュリティの穴なんです。

どういうことかというと、cookieはブラウザもしくはサーバに保存されているので、別サイトからリクエストが送られたときにも正しいcookieが使用されてしまう（認証が通ってしまう）のです。

画像にコマンドを仕込むなどすれば、リクエストを知らぬ間に送らせることは簡単なので、ユーザーが意図しないリクエストが通ってしまうことになります。

CSRF対策の定番

なので、Webアプリ側でそのような攻撃を防ぐ必要があるのですが、そのための方法として、アプリ内でリクエストをする際は認証用のtokenを差し込むというものがあります。

つまり、「お前味方か？」という確認をするということです。そしてその結果として必然的に、外からのリクエストをすべて弾くことになります。

Railsではありがたいことに、そのCSRF対策を自動生成してくれています。
それがapplication_controllerが作られるときに自動で書き込まれるprotect_from_forgeryメソッドです。

実は、RailsではViewでform_forやform_tagを使うと、自動でCSRF対策用のトークンを埋め込んでくれています。

そして、protect_from_forgeryによって、アクション実行前に正しいトークンが付随されているかをチェックしています。

逆に言えばこのメソッドの適用外は自分で対策をしなければならないということでもあります。

じゃあ、AjaxでPOST送信したいときは、form_forなどを使ってないので自分で対策しなくてはいけないかというと、Railsはここまでカバーしてくれています。

Ajaxの場合、Ajax送信する直前に実行されるメソッドで、トークンを指定しているようです。

このメソッドはCSRF対策しているから大丈夫、しなくても大丈夫、だから外部からリクエストできるようにしたい。という場合はこんな回避方法があるようです。

protect_from_forgery with: :null_session コントローラーごとしなくてOKの場合は、こうすると良いようです。APIを作るとき用のものみたいですね。ー参考 Rails 4.0だとCSRFトークンでエラーになる
protect_from_forgery :except => [:action] そのメソッドだけというときはexceptで指定すると良いようです。ー参考 Rails4のCSRF対策で「Can't verify CSRF token authenticity」エラー