私は、すべての動的コンテンツがAjaxリクエストを使用してJSONとして取得されるWebアプリケーションを開発しています。GET API呼び出しが異なるオリジンから呼び出されないように保護する必要があるかどうかを検討していますか？
GETリクエストは状態を変更せず、一般的な知恵は、CSRF保護を必要としないということです。しかし、ブラウザがそのようなリクエストの結果を別のオリジンサイトにリークするというコーナーケースはないのだろうか？
たとえば、別のオリジンサイトが/ users / emailsをスクリプト、css、またはimgとして取得した場合、ブラウザーが結果のjsonを呼び出し元のサイトにリークする可能性がありますか（たとえば、javascript onerrorハンドラーを介して）？
ブラウザは、クロスオリジンJSON応答のコンテンツがリークされないことを十分に保証しますか？クロスオリジンコールからGETリクエストを保護することは理にかなっていると思いますか、それともやり過ぎですか？
あなたはコーナーケースを釘付けにしましたが、それでも非常に関連性の高い問題です。確かに、この可能性があり、参照する相手に応じて、JSONインクルージョンまたはクロスサイトスクリプティングインクルージョンまたはJavascriptインクルージョンと呼ばれます。攻撃は、基本的に、悪意のあるサイトで実行し、jsエンジンが解析した後、javascriptを介して結果にアクセスすることです。
簡単に言うと、すべてのJSON応答は、配列やJSONPではなくオブジェクトに含まれている必要があります（つまり、{...}）。より適切に測定するには、すべての応答を接頭辞（while（1）、for （;;）またはパーサーブレーカー）。FacebookまたはGoogleのJSON応答を見て、実際の例を確認してください。または、CSRF保護を使用してURLを推測できないようにすることもできます。どちらの方法でも機能します。
いいえ：
これはCSRFの問題ではありません。純粋なJSONを返し、GETが副作用のない限り、csrfで保護する必要はありません。
Paradoxengineが言及したのは、もう1つの脆弱性です。JSONPを使用している場合、攻撃者が認証されたユーザーに送信されたJSONを読み取る可能性があります。非常に古いブラウザ（IE 5.5）のユーザーも、通常のJSONを使用してもこの方法で攻撃される可能性があります。
別のドメインにリクエストを送信することはできますが（CSRF攻撃が行うことです）、レスポンスを読み取ることはできません。
ここから別のスタックオーバーフローの質問でこれを学びますCSRFを間違って理解しているようですか？ これが質問の理解に役立つことを願っています。