私はオンライン情報から少し混乱しています。AJAX GETメソッドによるCSRFトークン保護
バックエンドでSpringセキュリティを使用してCSRF保護を使用しています。
Ajax GETメソッドを使用してHTTPヘッダー内のトークンを渡している間に、私のフロントエンドからCSRFトークンを送信するのは安全ですか？
私はGETメソッドを使用すべきではありませんが、HTTPヘッダーに渡すときにGET Ajaxを使用しても問題ないと言います。
第二に、
私がGET使用してはならない場合は、どのように私はRESTサービス& CSRF保護を使用していますか？私はGETメソッドまたはCSRF保護を放棄すべきですか？
GET要求はサーバー上の状態を変更すべきではないため、通常は「読み取り専用」にする必要があるため、通常はGET要求に対してCSRF保護は必要ありません。
GET要求には通常本体が含まれておらず、したがってトークンが要求パラメータとして送信されるため、漏洩に関する問題は主にブラウザの使用に関連します。したがって、CSRFトークンは、ショルダーサーフィン、ブックマークとして保存、ブラウザ履歴への表示、またはサーバーへのログ記録（AJAX要求にもロギングが適用されます）に表示されます。
あなたはAJAXリクエストについて話しているので、この漏れのほとんどは当てはまりませんが、ヘッダーに設定するとURLに表示される場合に役立ちますが、ログにもヘッダーが含まれる可能性があります。 AJAXリクエストがカスタムヘッダーを設定し、他のクロスドメイン
しかし、実際に（またはトークンなし）カスタムヘッダを使用しては、多くの場合、
したがって、X-Requested-With: XMLHttpRequestのようなカスタムヘッダーを使用します。 jQueryによって設定され、サーバー上のこのヘッダーを検証することでCSRF攻撃を防ぐことができます。
GETおよびPOST要求に同じトークンを持ち、同じ起点にある別のWebアプリケーションのXSS脆弱性を介してGET要求への同じ起点アクセスを持つことについてトークンがあることについては、interesing articleが1つありますGET要求から漏洩し、POSTのために使用される。解決策は、GETにCSRFトークンを使用しないか、GETとPOSTに異なるトークンを使用することです。
あなたの質問に関しては、GETに副作用がない場合、CSRFトークンは本当に必要ではありませんが、傷つけることはありません。一方、GETリクエストによってサーバー上で何かが変更された場合は、実行する内容に応じて別の動詞（POSTなど）を使用し、POSTリクエストをCSRFトークンまたはカスタムヘッダーで保護することを検討する必要があります。