我正在设计一个可从 Web 浏览器访问的 RESTful API。API 受基本身份验证保护。

我了解 CSRF 的概念以及提出的缓解措施（我发现Wikipedia CSRF 条目和OWASP CSRF 页面都有很好的解释）。它们通常会引入一些客户端需要保留并呈现给服务器的状态，因此服务器知道请求仍然来自正确的客户端。

不过，我正面临着客户端实现因此变得非常“肮脏”的问题，我想知道是否有更清洁的解决方案。具体来说，不需要处理额外的状态。

我正在考虑但想与您一起检查的一种解决方案是使用一些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？