Protección contra CSRF en configuraciones de React y API

Cross-Site Request Forgery (CSRF) es un ataque en el que un sitio web malicioso engaña al navegador del usuario para que envíe una solicitud autenticada a su API. Como el navegador adjunta automáticamente las cookies a las solicitudes, el servidor no puede distinguir entre una solicitud legítima de su aplicación y una solicitud falsificada desde el sitio del atacante.

Las cookies son la causa principal de la vulnerabilidad CSRF. Cuando un usuario inicia sesión en su aplicación, la cookie de sesión se almacena en el navegador. Cuando visita la página del atacante, este puede activar el envío de un formulario o una solicitud fetch a su API, y el navegador incluye automáticamente la cookie de sesión, autenticando así la solicitud maliciosa.

El atributo de cookie SameSite indica a los navegadores cuándo deben incluir cookies en solicitudes entre sitios. Tiene tres valores: Lax (el valor predeterminado en los navegadores modernos; bloquea POST entre sitios, pero permite GET), Strict (bloquea todas las solicitudes entre sitios, incluidas las navegaciones GET) y None (permite solicitudes entre sitios y requiere el indicador Secure con HTTPS).

SameSite=Lax bloquea las solicitudes POST, PUT, DELETE y PATCH entre sitios: los métodos utilizados para realizar mutaciones. Si su API utiliza GET únicamente para lecturas y POST para todas las mutaciones, SameSite=Lax evita eficazmente CSRF en las SPA de los navegadores modernos. Esta es la mitigación básica en la que se apoyan actualmente la mayoría de las aplicaciones.

El patrón de doble envío de cookie es una mitigación de CSRF en la que el servidor establece un token CSRF aleatorio en una cookie que no es HttpOnly. El cliente lee el valor de esta cookie y lo incluye como una cabecera de solicitud personalizada (por ejemplo, X-CSRF-Token). El servidor verifica que el valor de la cabecera coincida con el de la cookie. Un atacante no puede leer la cookie desde otro origen, por lo que no puede establecer la cabecera correcta.

El patrón del token sincronizador genera un token CSRF único por cada sesión de usuario en el servidor. En los formularios HTML, el token se inserta en un campo oculto. En las llamadas a la API de una SPA, el token se proporciona mediante un endpoint o una etiqueta meta y se envía en una cabecera personalizada. El servidor valida el token en cada solicitud que modifica el estado.

Una SPA de React que almacena su JWT en memoria o en localStorage y lo envía en una cabecera Authorization: Bearer no es vulnerable al CSRF clásico. Los ataques CSRF explotan la autenticación basada en cookies; la página de un atacante no puede establecer cabeceras personalizadas en solicitudes entre orígenes debido a las restricciones de CORS, por lo que no puede falsificar la cabecera Authorization.

Las solicitudes simples entre orígenes (POST de un formulario o carga de una imagen) no permiten cabeceras personalizadas. Solo las solicitudes que pasan por la comprobación previa de CORS pueden incluir cabeceras personalizadas, y las solicitudes con comprobación previa requieren autorización explícita del servidor. Una API que exige una cabecera personalizada (como X-Requested-With: XMLHttpRequest) para todas las mutaciones está protegida de forma inherente frente a los ataques CSRF simples.

CORS controla qué orígenes pueden leer la respuesta de una solicitud de origen cruzado. CSRF se refiere a qué orígenes pueden realizar solicitudes que cambian el estado. Configurar CORS para restringir los orígenes no evita CSRF: el navegador sigue enviando la solicitud y la cookie; CORS solo controla si la respuesta es visible para JavaScript. Un ataque CSRF no necesita leer la respuesta.

Configure las cookies de sesión con: HttpOnly: true (evita que JavaScript lea la cookie y bloquea el robo de tokens basado en XSS), Secure: true (solo se envía mediante HTTPS), SameSite: Lax o Strict (evita CSRF), y un Max-Age o tiempo de expiración adecuados. Estos cuatro atributos refuerzan considerablemente la gestión de sesiones.

Next.js App Router utiliza Server Actions, que son solicitudes POST. Next.js implementa protección contra CSRF comprobando la cabecera Origin frente al host; las solicitudes de orígenes inesperados se rechazan. Esta comprobación integrada, combinada con cookies de sesión SameSite=Lax, proporciona una protección sólida contra CSRF para las mutaciones basadas en Server Actions.

¿Qué valor de la cookie SameSite bloquea las solicitudes POST entre sitios, pero permite las navegaciones GET entre sitios?

CSRF aprovecha la autenticación basada en cookies al engañar al navegador para que envíe solicitudes autenticadas entre sitios. SameSite=Lax es la defensa básica en los navegadores modernos. Los patrones Double Submit Cookie y Synchronizer Token proporcionan protección adicional. Las SPA de React que usan JWT en cabeceras Authorization son inherentemente resistentes a CSRF. Las cabeceras personalizadas obligatorias y el preflight de CORS también mitigan CSRF. Combine siempre HttpOnly + Secure + SameSite en las cookies de sesión.