Securización de APIs REST

Tome la configuración de una aplicación web clásica, apunte un cliente JavaScript hacia ella y observe: en lugar de un 401 limpio, su llamada fetch recibe un 302 hacia una página de inicio de sesión HTML. El cliente, que esperaba JSON, intenta analizar HTML y falla con un mensaje incomprensible. Sin embargo, nada está roto: Spring Security hace exactamente lo que se le ha pedido, es decir, comportarse como si un navegador siguiera un flujo de inicio de sesión.

Este es el primer ajuste que hay que hacer: una API no redirige, responde con un código. El segundo afecta al estado. Una aplicación con sesión almacena la identidad en el servidor y la recupera mediante una cookie; una API sin estado exige que cada petición lleve su propia prueba de identidad. Ambos modelos funcionan, pero no tienen las mismas vulnerabilidades, y las protecciones adecuadas para uno no lo son para el otro.

Aquí es donde se producen los dos errores más extendidos del ámbito. El primero consiste en copiar csrf.disable() sin preguntarse qué hacía necesaria esa protección, y en desactivarla también en las partes de la aplicación que utilizan cookies. El segundo consiste en tratar CORS como un mecanismo de seguridad, cuando no lo es, y abrir un acceso creyendo que se está controlando.