それは CSRF 保護の目的ではありません。CSRF 保護は、データがサイトに直接投稿されるのを防ぐためのものです。つまり、クライアントは実際に承認されたパスを介して投稿する必要があります。つまり、フォーム ページを表示し、入力し、データを送信します。
API は CSRF をほとんど排除します。これは、その全体的な目的が一般に、サードパーティのエンティティがサイト (CSRF の「クロスサイト」) のデータにアクセスして操作できるようにすることであるためです。したがって、はい、原則として、どの API ビューも CSRF を免除する必要があると思います。ただし、それでもベスト プラクティスに従い、OAuth などの何らかの形式の認証で実際に変更を行うすべての API エンドポイントを保護する必要があります。
CSRF 攻撃は、特定のドメインへのすべてのリクエストで暗黙的に送信される Cookie に依存しています。API エンドポイントで Cookie ベースの認証が許可されていない場合は、問題ありません。
Cookie ベースの認証を使用する場合でも、iOS アプリは Cookie を共有しないため、Cookie は安全です。ただし、通常とは異なるユーザー エージェント ヘッダーを要求して Web ブラウザーを意図的にブロックしない限り、API を使用するブラウザー ベースのアプリを第三者が作成する可能性があります。また、API が Cookie ベースの認証をサポートし、Cookie ベースの認証をサポートしていない場合、そのアプリは CSRF 攻撃に対して脆弱になります。 CSRF 保護を適用しません。
API を使用して Web サイトをサポートしている場合にも適用されます。
この場合、誰かが他のサイトにリクエストを埋め込んで、認証されたユーザーのアカウントにドライブバイ効果を与えるのを防ぐために、なんらかの形式の CSRF 保護が必要です。
Chrome はデフォルトでクロスオリジン POST リクエストを拒否するようですが (他のブラウザはそれほど厳密ではないかもしれません)、クロスオリジンの GET リクエストを許可するため、API の GET リクエストに副作用がないことを確認する必要があります。