ログインページで偽造防止トークンを使用しないことはいつ許可されますか？
この投稿 には、ログインページで偽造防止トークンを検証する必要がないシナリオについて言及する段落があります。
偽造防止トークンを省略してもよいのはいつですか？一般に、ターゲットがURLであり、そのURLにアクセスしても副作用がない場合、そのURLに偽造防止トークンを含める必要はありません。
CSRF攻撃がどのように機能するかは理解していますが、この段落では残念ながらかなり迷っています。それは言う：
- ターゲットがURLの場合
- そのURLにアクセスしても副作用がない場合
URLではないターゲットはありますか？そして「副作用」の例は何ですか？
Subdomain.domain.comなどのURLでホストされているASP.NET MVCアプリケーションがあります。ユーザーに次のエラーが表示されます。
「提供された偽造防止トークンは、現在のユーザーとは異なるクレームベースのユーザーを対象としています。」
「偽造防止Cookieトークンとフォームフィールドトークンが一致しません。」
「提供された偽造防止トークンはユーザー ""向けでしたが、現在のユーザーは> "XYZ"です。 "
言い換えると、私の質問は、ログインページで偽造防止トークンを使用しないことで問題がないというシナリオです
URLにアクセスすると、副作用が発生する可能性があります。たとえば、Amazonにログインしている場合、URLにアクセスすると、アイテムが購入されて私に送られます（ワンクリック購入）。それは副作用です。または、ログアウトしたり、ログインしたり、一部の設定を更新したりすることもあります。これらも副作用です。
一般に、サーバー上の一部の（永続的な）状態を変更した場合、または世界に対して永続的な監視可能な効果がある場合、操作には 副作用 があります。
私の理解では、ブラウザーが自動的に認証資格情報をURLに送信するため、認証資格情報を保管するCookieが本当の問題です。 Cookieを使用せず、リクエストに応じて常に認証データを送信するスクリプトがない場合は、偽造防止トークンは必要ありません。考えてみれば、それを使っても意味がありません。 JWTトークンまたは他のトークン（一意の文字列）のみを使用する場合、これは偽造防止トークンを送信することと同じです。これは、最終的に偽造防止トークンがあるためです。 SSLまたはTLSも使用する必要があります。
一般的なルール：Cookieを使用しないでください。それらは悪いデザインパターンであることが何度も証明されています。
クロスサイト要求自体によって実行されるアクションが取るに足らない場合は、CSRF保護は必要ありません。しかし、アプリケーションのコンテキストで永続的な後遺症を持つすべてのアクションに対して、このような保護を設けることが理想的です。
例えば：
構成ファイルのファイルアップロードには、CSRFトークンが必要ですが、情報のみを表示する単純な検索クエリでは必要ありません（アプリケーションのCORS設定が正しく設定されている場合）。
ログインページの場合、失敗したログインアクション自体がアプリケーションのコンテキストに永続的な変更を作成しない限り、通常は必要ありません。