Estoy diseñando una API RESTful a la que se puede acceder desde un navegador web. La API está protegida por autenticación básica.
Entiendo el concepto de CSRF y las mitigaciones propuestas (encontré entrada de Wikipedia en CSRF y OWASP CSRF page buenas explicaciones). Por lo general, presentan algún estado que el cliente debe conservar y presentar al servidor, por lo que el servidor sabe que las solicitudes aún provienen del cliente correcto.
Me estoy enfrentando, sin embargo, a que la implementación del cliente se vuelve muy "sucia" debido a eso y me preguntaba si podría haber soluciones más limpias. Específicamente, uno que no requeriría manejar un estado adicional.
Una solución en la que estoy pensando, pero que quería consultar contigo, es usar un encabezado Authorization que no sea Basic .
De acuerdo con RFC 2617, sección 2, con respecto al esquema de autenticación Basic , el nombre de usuario y la contraseña pueden ser almacenados en caché por el navegador y reenviarse sin preguntar al usuario bajo ciertas condiciones, y eso es lo que lo hace vulnerable a 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.
También verifiqué que Authorization: OAuth (usado en puntos finales autenticados OAuth 1.0) y Authorization: Bearer (usado en puntos finales autenticados OAuth 2.0) no son enviados automáticamente por el navegador.
Por lo tanto, mi pregunta es: ¿consideraría que un punto final protegido por los encabezados de autorización de OAuth / Portador debería tomar precauciones adicionales para evitar el CSRF?