同期トークンとCookie-to-HeaderパターンがWeb APIにとって不自然なのはなぜですか？
CSRF防止技術はWeb APIにとって自然なものではないと聞きました。
たとえば、domainAに 同期トークンパターンとCookie-to-Headerパターン の両方を実装するクライアントアプリケーションがあるとします。クライアントがdomainBのリソースサーバーにPOSTするとき、リソースサーバーはそれらのセキュリティ値を検証する必要があります。リソースサーバーは、どの同期トークン値も、どのcookie-to-header値も期待できないのかわからないため、困難になります。それらを検証します。
つまり、リソースサーバーは、アクセストークンの検証に使用するのと同じ手法を使用して、同期トークンやcookie-to-header値を検証できます。それでは、なぜこれらの2つの手法がWeb APIに不適切であると考えられるのでしょうか。
Web CSRFフローでは、サーバーはWebページを提供する応答の一部としてトークンを送信するため、トークンは「無料」で配信されます。通常、同じサーバーがこれらのPOST=リクエストのターゲットでもあるため、トークンを簡単に検証できます。
Web APIを呼び出す場合、ターゲットはおそらく別のサーバーであるため、トークンは帯域外で通信されるか、クライアントが後続のリクエストでトークンを使用するためだけにリクエストを送信する必要があります。どちらの場合でも、Web APIサーバーは要求の2倍の数を処理しますが、これは無駄です。
適切な代替手段は、デジタル署名スキーム、またはブラウザで許可されていないHTTPメソッド/ヘッダーです。