Tengo una API REST que usa un token de acceso que se envía en el encabezado o como consulta de URL. No uso cookies en absoluto.
¿Sigo siendo vulnerable a los ataques CSRF? Sé que lo haría si usara cookies, ya que otras pestañas pueden enviar solicitudes y también se enviarán cookies, pero en mi caso, Headers / UrlParam no se enviarán en absoluto.
CSRF aún sería posible si está utilizando la autenticación HTTP Basic o HTTP Digest. La razón es que los navegadores implementan esos protocolos "de forma nativa", lo que significa que el explorador insertará automáticamente las credenciales con cada solicitud dirigida a un dominio en particular.
Si está utilizando alguna otra forma de autenticación sin cookies, entonces no es posible CSRF.
Aquí hay un buen enlace que explica esto: OWASP CSRF
De su pregunta no está claro si usted es vulnerable o no. ¿El token es fijo o es un token generado al azar criptográficamente fuerte? si está arreglado no tiene ningún valor.
¿Está utilizando SSL? Si no, su token puede ser rastreado y robado, es altamente recomendable que utilice SSL.
Tenga en cuenta también que no se recomienda pasar el token en la url. Las URL son confidenciales, ya que están sujetas al registro en muchos lugares, como el historial del navegador, dispositivos de red, etc. enlace
¿Cómo se valida en el lado del servidor que el token es válido? ¿Lo mantienes en la sesión del servidor? Por lo general, las API de REST están diseñadas para ser sin estado, lo que significa que no se debe mantener ninguna sesión. Si desea atenerse a esta regla, debe crear el token en una cookie de solo http y en cada llamada a la API enviar el valor de la cookie como parte de la solicitud. Su API debería verificar que el valor de la cookie sea el mismo que el token en la solicitud. Un atacante no pudo leer la cookie y, por lo tanto, no podría enviar el token correcto en la solicitud.
este es un buen blog al respecto: enlace
Eso parece una forma correcta de protegerse contra el ataque CSRF. Sin embargo, es posible que desee generar un token nuevo en cada solicitud e invalidar los tokens utilizados anteriormente.