¿Activar CORS te protege del CSRF?
Respuesta breve
No. CORS no es una defensa contra el CSRF: en realidad afloja la política del mismo origen para que una página pueda leer respuestas entre orígenes que de otro modo no podría. El CSRF no necesita leer la respuesta; solo necesita que el navegador de la víctima envíe una petición autenticada que cambie el estado. Las defensas reales son los tokens anti-CSRF, el atributo de cookie SameSite y comprobar Origin/Referer.
Esta es una trampa de nivel senior porque los dos acrónimos suenan relacionados y ambos implican «entre orígenes». Muchos ingenieros asumen que CORS es un muro de seguridad. En realidad CORS relaja un muro, y aborda un problema distinto del CSRF.
Qué hace realmente CORS
La política del mismo origen normalmente impide que el JavaScript del sitio A lea la respuesta de una petición al sitio B. CORS es el mecanismo por el cual el sitio B puede optar por permitir que el sitio A lea sus respuestas. Así que CORS trata de relajar restricciones de lectura, no de bloquear peticiones. Una configuración CORS restrictiva simplemente significa que otros orígenes no pueden leer tus respuestas; no hace nada para impedir que una petición se envíe.
Por qué al CSRF no le importa
Un ataque CSRF se monta sobre la sesión ya autenticada de la víctima. La página del atacante dispara una petición que cambia el estado (transferir fondos, cambiar el correo) y el navegador adjunta automáticamente las cookies de la víctima. El atacante nunca necesita leer la respuesta: el daño lo causa el efecto secundario. Muchas de esas peticiones (un simple POST de formulario, un GET de imagen) son «peticiones simples» que ni siquiera disparan una verificación previa de CORS. Así que CORS, que solo gobierna la lectura, es irrelevante para el ataque. El distractor que dice «detiene GET pero no POST» malinterpreta por completo cómo funciona esto.
Las defensas reales
- Tokens anti-CSRF: un token impredecible por sesión/por petición que el atacante no puede adivinar.
- Cookies SameSite (Lax/Strict): el navegador retiene la cookie en las peticiones entre sitios.
- Validar Origin/Referer en los endpoints que cambian el estado.
Qué buscan los entrevistadores
Un «no» claro, la distinción lectura frente a envío, y las mitigaciones correctas. Confundir CORS con una defensa CSRF es un error común y revelador.
Posibles preguntas de seguimiento
- ¿Cuál es la diferencia entre lo que controla CORS y lo que impone la política del mismo origen?
- ¿Cómo mitiga el atributo de cookie SameSite el CSRF, y cuáles son sus límites?
- ¿Por qué un simple POST de formulario es un riesgo CSRF incluso con una configuración CORS restrictiva?