flawopen.com/CSRF/Solicitudes GET
Token CSRF en GET: ¿cuándo se necesita?
Si GET solo recupera datos, no debe cambiar el estado del servidor y normalmente no necesita un token CSRF. Navegadores, rastreadores, vistas previas y recursos incrustados pueden emitir GET sin un clic intencionado. Usa un método no seguro para acciones como borrar o comprar y protege contra CSRF los cambios autenticados mediante cookies. Un GET heredado que cambia el estado sigue siendo vulnerable y necesita una defensa temporal mientras se migra.
Por qué GET debe seguir siendo seguro
RFC 9110 define GET como seguro: el cliente no solicita un cambio de estado. Seguro no significa que el servidor no tenga efectos incidentales, como registrar solicitudes. GET también es idempotente, pero son propiedades distintas. Navegadores, precargas, rastreadores y vistas previas pueden emitir solicitudes seguras sin una acción deliberada del usuario. Un <img src="..."> en otro sitio también puede hacer que el navegador envíe GET con las cookies del usuario. Si el endpoint borra algo o cambia la cuenta, incumple la semántica de GET y puede activarlo contenido corriente de una página.
Aplica defensas CSRF a las solicitudes que cambian el estado
- ✓Mantén GET, HEAD y OPTIONS libres de cambios de estado solicitados; usa POST, PUT, PATCH o DELETE para las mutaciones
- ✓Protege los métodos no seguros autenticados con cookies mediante la defensa CSRF del framework o un token validado; usa SameSite y comprobaciones de Origin/Fetch Metadata como capas adicionales
- ✓Trata cualquier GET que cambie el estado como un error de semántica HTTP; añade una defensa CSRF temporal si hace falta, migra la acción y elimina secretos de las URL
Preguntas frecuentes sobre CSRF en GET
Trátalo como vulnerable. Exige temporalmente una defensa CSRF validada en el servidor (por ejemplo, un token sincronizador junto con comprobaciones de Origin o Fetch Metadata cuando estén disponibles), audita cachés y referers, y migra la acción a POST, PUT, PATCH o DELETE. Evita los tokens en la query string: las URL pueden aparecer en el historial, los registros y los datos de referer. La comprobación del token es provisional hasta que el endpoint respete la semántica de los métodos seguros.