.png)
Tu plataforma puede estar funcionando de maravilla desde el punto de vista funcional, pero antes de ir a producción hay una tarea ineludible: revisar que no existan vulnerabilidades de ciberseguridad. De repente un compañero pregunta por qué tenemos esto en la configuración de seguridad: httpSecurity.csrf((csrf) -> csrf.disable()); ¿No deberíamos estar protegidos también frente a CSRF?
Si te suena lejano, piensa en esta analogía. Alice y Eve están usando ordenadores lado a lado. Eve es maliciosa, pero sin mirar la pantalla de Alice. Cuando Alice se levanta a por un té, Eve conecta su propio teclado al puerto USB del equipo de Alice. Al volver Alice y desbloquear la sesión, Eve puede teclear acciones maliciosas como enviar dinero o borrar una base de datos. El ataque funciona porque el ordenador no puede distinguir si escribe Alice o un teclado ajeno.
CSRF significa Cross Site Request Forgery. En vez de dos teclados en el mismo equipo, tenemos dos peticiones HTTP saliendo del mismo navegador. Una es un inicio de sesión legítimo en una aplicación web, por ejemplo banca online, que deja una cookie de sesión en el navegador. Otra es una petición enviada desde un sitio malicioso que imita exactamente la operación de enviar dinero. El navegador adjunta automáticamente la cookie de sesión y el servidor cree que la petición es auténtica y la ejecuta.
Cómo se mitiga CSRF. Debemos evitar que las peticiones sensibles sean adivinables. Para ello se añade a la solicitud un valor dinámico y aleatorio que se envía de forma explícita y que no sea una cookie. La protección CSRF en frameworks como Spring valida ese parámetro adicional incluido en la petición HTTP y lo compara con el esperado.
La buena noticia es que los API REST bien diseñados no dependen de cookies de sesión porque son stateless. También en autenticación, donde el método preferido es OpenID Connect sobre OAuth 2.0. En estos casos se envía un token de acceso en formato JWT dentro de la cabecera Authorization en cada petición. Por eso, en APIs sin autenticación basada en cookies, es válido desactivar la protección CSRF con algo como httpSecurity.csrf((csrf) -> csrf.disable());. En cambio, si tu frontend de navegador usa sesiones con cookies, mantener CSRF activado es esencial.
Si quieres profundizar, aquí tienes lecturas recomendadas: ¿Necesito token CSRF si uso Bearer JWT? y ¿Debo usar protección CSRF en endpoints REST?. La guía oficial de Spring sobre este tema es una referencia excelente: CSRF en Spring Security.
Por qué en la analogía Eve no miraba la pantalla. CSRF es un ataque de solo escritura. La lectura de respuestas desde otro origen está bloqueada por la política del mismo origen, una protección de los navegadores de largo recorrido que impide robar datos entre dominios distintos. Puedes revisar la política del mismo origen aquí: Same origin policy. Ahora bien, con frontends complejos en JavaScript y contenido servido desde CDNs, a veces hay que relajar esta política con CORS Cross Origin Resource Sharing, que conviene configurar con precisión.
En Q2BSTUDIO ayudamos a diseñar, construir y desplegar APIs seguras y escalables, desde el backend hasta el frontend. Somos una empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y automatización. Si quieres auditar tus endpoints, validar tu estrategia de tokens JWT, OIDC y CORS, o necesitas pentesting y hardening, revisa nuestros servicios de ciberseguridad y pentesting.
Además, si tu plataforma vive en la nube y deseas buenas prácticas de seguridad de red, secretos, identidad y observabilidad, te acompañamos con arquitectura y despliegues en servicios cloud aws y azure. Integramos autenticación moderna, cifrado y monitorización con soluciones de ia para empresas, agentes IA y analítica avanzada para que tu software a medida y tus aplicaciones a medida evolucionen con garantías. También podemos potenciar tus cuadros de mando con power bi dentro de una estrategia completa de servicios inteligencia de negocio.
Conclusión. Desactivar CSRF en un API REST stateless que no usa cookies de sesión es correcto y recomendado, siempre que la autenticación se base en tokens y que se apliquen controles complementarios como validación estricta de orígenes, CORS bien definido, scopes granulares y caducidad de tokens. Para aplicaciones web con sesión en navegador, mantén CSRF activo. Si necesitas una revisión integral, en Q2BSTUDIO estamos listos para ayudarte a llevar tu plataforma a producción con seguridad y sin fricciones.
