トークン認証時のCSRF対策の必要性について

rails（APIサーバー）とangular（フロントエンド）でwebアプリケーションを構築しているものです。

認証方式はバックはdevise_token_auth、フロント側はangular-tokenを利用しており、
いわゆるセッション管理による認証ではなく、httpヘッダーにトークンを入れて認証するスタイルです。
モバイルアプリからAPIを利用する際の構成に近いと思います。

質問内容なのですが、いくつかのブログ記事でサーバー側のCSRFチェック機構をオフにするようなセットアップ内容が書かれていました。例えばこちらです
https://qiita.com/wktq/items/8a4653153af47933c169
railsではprotect_from_forgeryを利用してCSRFチェックするのですが、これがオフとされていました。

これは、
「認証方式がトークン式のため、CSRF攻撃者からヘッダー情報に認証用トークンを仕込むことができない（正確には認証用トークンを読み込むことができない）ため、不要としている」
という認識で合っているのでしょうか？？

いくつか情報を検索したのですが、確信が持てず...。
ご教示いただけますと幸いです。

<追記: rails, deviseをご利用の同状況の方へ>

仮にdevise_token_authとdeviseを同居させる場合、上記例外ケースに該当しないことになります。deviseは基本的にはセッションを利用した認証になりますので、devise_token_auth以外での認証も行う場合はご注意ください。
その場合はこちらのIssueに記載の内容に則して、application_controllerでなく、overrideしたコントローラーを作成してそちらでprotect_from_forgeryを無効化するのがおすすめです。

行動規範の内容に同意します

回答1件

ベストアンサー

ご質問の状況ではあれば、確かにCSRF脆弱性にはならないと思います。
IPAの「安全なウェブサイトの作り方」にて、CSRF攻撃を受ける可能性があるサイトを以下のように説明しています。

次の技術を利用してセッション管理を実装しているウェブサイトが、CSRF攻撃による影響を受ける可能性があります。

Cookieを用いたセッション管理

Basic認証

SSLクライアント認証

「httpヘッダーにトークンを入れて認証するスタイル」は上記に該当しません。
ではなぜ問題ないかというと、CSRF攻撃では、利用者のブラウザから攻撃対象サイトにリクエストを送信する際に、自動的に認証情報やセッションIDが送信される必要があるからです。クッキーはこれに該当しますが、HTTPヘッダにトークンを埋め込むのは自動的にはされないので、CSRF攻撃の懸念はないと言えます。
ということで、下記の認識で問題ありません。