Protecciones que vienen y alguien desactivó

La protección contra peticiones falsificadas entre sitios (CSRF) viene encendida en Django, en Laravel y en Spring Security. Las tres funcionan igual en lo esencial: una petición que cambia datos tiene que traer un valor que solo la página legítima conoce, y que otro sitio no puede adjuntar aunque el navegador de la víctima envíe su cookie de sesión.

De ahí sale la regla para juzgar una excepción. Si quien llama no es un navegador con sesión, sino otro servidor que no usa cookies, el token no aporta nada y se sustituye por un control propio, como la firma del aviso de una pasarela. La documentación de Spring recomienda apagarla solo en servicios que no usan clientes de navegador. Si quien llama es un navegador con cookies, la excepción deja la ruta abierta, sea cual sea el motivo.

En Django, la protección la aplica CsrfViewMiddleware a toda la aplicación, y el decorador csrf_exempt la quita de una vista concreta. Que el middleware esté en la lista no dice nada de las vistas exentas: hay que buscarlas en el código y juzgar cada una con tres preguntas. ¿Cambia datos? ¿La llama un navegador con sesión? ¿Hay un control que sustituya al token?

Abre tienda-middleware.txt para confirmar que la protección general está activa y después tienda-exenciones.txt para juzgar cada exención.

En Laravel, la comprobación la hace el middleware ValidateCsrfToken, que va dentro del grupo web. Las rutas que no deben pasar por él se declaran en bootstrap/app.php con validateCsrfTokens(except: [...]), y la documentación sugiere, para avisos de un tercero, sacarlas directamente del grupo web. Cada entrada de esa lista acepta comodines, y un comodín cubre todas las rutas que hay debajo, también las que se escriban el año que viene.

Lee el extracto de bootstrap/app.php y cruza cada entrada con autores-rutas.txt: quién llama a cada ruta y qué cambia.

En Spring Security la protección CSRF también viene encendida, y se puede quitar para toda la aplicación con una línea o solo para un grupo de rutas con ignoringRequestMatchers. Una API que se autentica con un token en la cabecera Authorization y no usa cookies no la necesita; un panel con formulario de acceso y cookie de sesión sí, aunque viva en la misma aplicación.

Lee distribucion-seguridad.txt, después distribucion-rutas.txt y el cambio de febrero en historial-cambios.txt.

El historial cuenta la misma historia tres veces: algo daba error, alguien apagó la protección para que funcionara y el cambio no pasó por revisión. Las dos excepciones que sí se revisaron están bien hechas. Lo que corrige el patrón es reponer cada protección, dejar fuera solo lo que tiene un control propio y que una prueba automática falle cuando una protección desaparece o una excepción se amplía.