OAuthまたはBearer Authorizationヘッダーを含むCSRF
WebブラウザーからアクセスできるRESTful APIを設計しています。 APIは基本認証によって保護されています。
私はCSRFの概念と提案された緩和策を理解しています（ Wikipedia CSRFエントリ と OWASP CSRFページ の良い説明の両方を見つけました）。それらは通常、クライアントが保持してサーバーに提示する必要があるいくつかの状態を導入するため、サーバーは要求が正しいクライアントからまだ送信されていることを認識します。
しかし、私はクライアントの実装がそのために非常に「ダーティー」になることに直面しており、よりクリーンな解決策があるかどうか疑問に思っていました。具体的には、追加の状態の処理を必要としないもの。
私が考えている1つの解決策は、あなたと一緒にチェックアウトしたいのですが、AuthorizationではないBasicヘッダーを使用することです。
RFC 2617のセクション2によると、Basic認証スキームに関して、ユーザー名とパスワードはブラウザによってキャッシュされ、特定の条件下でユーザーに確認せずに再送信される可能性があります。これにより、CSRFに対して脆弱になります。 ：
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
また、Authorization: OAuth（OAuth 1.0認証済みエンドポイントで使用）およびAuthorization: Bearer（OAuth 2.0認証済みエンドポイントで使用））は、ブラウザによって自動的に送信されません。
だから、私の質問です：OAuth/Bearer認証ヘッダーで保護されたエンドポイントは、CSRFを防ぐために追加の予防策を講じるべきだと思いますか？
APIにBasic（またはクライアント証明書、ダイジェスト、一部のブラウザーではNTLM）などの組み込みブラウザー認証スキームまたはCookie認証を使用していない限り、CSRFを心配する必要はありません。 。