En 05-01 añadimos una dependencia y la API de CicloUrbana quedó cerrada a cal y canto: un usuario llamado user, una contraseña que cambia en cada arranque, un formulario HTML que a una aplicación móvil no le sirve de nada y un 403 por CSRF cada vez que intentamos crear una estación. Es seguro, pero es inútil. Esta lección convierte ese andamio en una configuración deliberada.

Vamos a escribir la primera clase real del paquete com.ciclourbana.seguridad: ConfiguracionSeguridad, con su bean SecurityFilterChain. Aprenderemos la DSL de lambdas de Spring Security 6 apartado por apartado, definiremos el mapa completo de accesos de la red de Ribalta, entenderemos por qué el orden de las reglas es lo que más se equivoca todo el mundo, y tomaremos con criterio —no por costumbre ni por copiar de internet— las cuatro decisiones que definen el carácter de la API: contraseñas, CSRF, sesión y cabeceras. Al terminar, CicloUrbana tendrá cerraduras de verdad, aunque las llaves sigan siendo provisionales hasta 05-03.

Advertencia. Todos los usuarios, contraseñas y orígenes de esta lección son ficticios y sirven para el ejemplo. Las contraseñas en claro que aparecen aquí solo son admisibles en un ejemplo didáctico ejecutado en local; nunca se escriben en un fichero versionado. Toda configuración de seguridad debe ser revisada por un profesional de seguridad antes de exponerse a Internet.

1. El modelo de componentes de Spring Security 6
2. ConfiguracionSeguridad: la primera clase de .seguridad
3. La DSL de lambdas, apartado por apartado
4. authorizeHttpRequests y requestMatchers
5. La regla de oro del orden de las reglas
6. El mapa de accesos de CicloUrbana
7. Usuarios en memoria con InMemoryUserDetailsManager
8. Codificación de contraseñas
9. HTTP Basic y form login
10. CSRF: qué es y cuándo se puede desactivar
11. Gestión de sesión: STATELESS
12. Integrar la configuración CORS de 03-02
13. Cabeceras de seguridad de la respuesta
14. Varias cadenas con @Order y securityMatcher
15. Depurar la seguridad
16. Errores Comunes y Consejos
17. Ejercicios

Si buscas ejemplos de Spring Security en internet, la mitad de lo que encontrarás no compila. El motivo es un cambio de modelo:

WebSecurityConfigurerAdapter quedó obsoleto en Spring Security 5.7 y se eliminó en la 6.0. Si intentas extenderlo con Spring Boot 3.x, el código ni siquiera compila. La sustitución no es cosmética: es un cambio de filosofía, de herencia a composición.

Tres razones del cambio: la herencia obligaba a un objeto con estado cuyo comportamiento dependía de qué métodos se hubieran sobrescrito; no componía bien, porque dos configuraciones exigían clases internas con reglas de ordenación poco evidentes; y era incoherente con el resto de Spring Boot, donde todo se configura declarando beans (02-01).

La consecuencia práctica es que toda la configuración de seguridad de CicloUrbana serán beans en una clase @Configuration normal, exactamente igual que ConfiguracionCors (03-02) o ConfiguracionOpenApi (03-07).

Cuatro elementos que conviene entender uno a uno:

@Configuration es una clase de configuración normal (02-01); nada especial.

@EnableWebSecurity. Importa la configuración de la seguridad web. Con Spring Boot es opcional, porque la autoconfiguración ya la aplica, pero se pone por dos motivos: hace explícito que esa clase gobierna la seguridad, y es imprescindible cuando se quiere activar el modo de depuración (@EnableWebSecurity(debug = true), apartado 15).

HttpSecurity inyectado como parámetro es un constructor de cadenas con ámbito prototipo: Spring entrega una instancia nueva por cada bean SecurityFilterChain, ya preconfigurada. Nunca lo guardes en un campo ni lo compartas entre métodos.

http.build() construye la SecurityFilterChain con los filtros correspondientes a lo configurado.

El efecto de declarar este bean es total: sustituye por completo la configuración por defecto de Spring Boot. El usuario user con contraseña generada desaparece del log, el formulario de login desaparece y solo queda lo que escribas. Es un interruptor de todo o nada: no se «añaden» reglas a las de por defecto, se reemplazan.

HttpSecurity ofrece un método por cada aspecto configurable, y cada uno recibe una lambda que lo personaliza. Este es el esqueleto completo con el que trabajaremos:

Tres reglas de uso. Customizer.withDefaults() activa el aspecto con sus valores por defecto. Para desactivar se usa la lambda con disable(): .csrf(csrf -> csrf.disable()), o su forma abreviada .csrf(AbstractHttpConfigurer::disable). Y no llamar a un método no significa desactivarlo: si httpBasic no aparece, se aplica el valor por defecto de esa cadena. En Spring Security 6.1 y posteriores, además, los métodos encadenados sin lambda (.and(), .antMatchers()) están obsoletos o eliminados: la DSL de lambdas es la única forma soportada, y su indentación muestra a simple vista dónde empieza y acaba cada bloque.

Es el bloque más importante: define quién accede a qué. Su estructura es siempre una lista de parejas criterio → regla.

Los patrones son de tipo PathPattern (el mismo motor de @RequestMapping, 03-02):

La distinción entre * y ** causa muchos agujeros. Escribir requestMatchers("/api/v1/usuarios/*").hasRole("ADMIN") protege /api/v1/usuarios/7, pero no /api/v1/usuarios/7/alquileres, que queda gobernado por la regla siguiente. Ante la duda, **.

Un detalle de Spring Security 6: los antiguos antMatchers y mvcMatchers se unificaron en requestMatchers, que elige la implementación adecuada según haya o no Spring MVC en el classpath.

hasRole("ADMIN") y hasAuthority("ROLE_ADMIN") son equivalentes: el primero añade el prefijo ROLE_ automáticamente. La confusión que genera esto es constante y la desmenuzaremos en 05-03; por ahora basta la regla mecánica: con hasRole nunca escribas el prefijo, con hasAuthority escríbelo siempre si el rol lo lleva.

Las reglas se evalúan en el orden en que se declaran, y gana la primera que coincide. No la más específica: la primera. Este es el error más frecuente de todo el módulo, y produce agujeros silenciosos.

Una petición a GET /api/v1/usuarios coincide con la primera regla, que la deja pasar. La segunda no se consulta nunca. Y lo peor es que la aplicación arranca sin ninguna advertencia: los datos personales de todos los ciudadanos de Ribalta quedan públicos y nada lo indica.

Tres consecuencias prácticas:

1. Ordena de específico a general, siempre. Rutas concretas primero, comodines amplios después.
2. anyRequest() va al final y no puede repetirse. Si aparece antes de otra regla, Spring Security lanza un error al arrancar (Can't configure requestMatchers after anyRequest). Es la única protección que el framework ofrece contra este problema, y solo cubre ese caso.
3. Termina siempre con anyRequest().denyAll() o anyRequest().authenticated(). Es la política de denegación por defecto: cualquier endpoint nuevo que alguien añada mañana nace protegido en lugar de nacer abierto. Es la diferencia entre olvidarse de proteger algo (peligroso, silencioso) y olvidarse de abrir algo (molesto, evidente en el acto).

Antes de escribir código, la decisión de negocio. La red de Ribalta tiene tres perfiles: CIUDADANO (alquila bicicletas), OPERARIO (mantiene la flota) y ADMIN (gestiona la red y los usuarios).

Y la traducción a código, con las reglas ordenadas de específico a general:

Tres detalles del diseño. Las estaciones públicas usan /api/v1/estaciones/* y no /**, para que el comodín de un solo segmento no abra subrecursos futuros por accidente. El GET de bicicletas va antes que la regla general, porque la primera coincidencia gana. Y anyRequest().denyAll() cierra cualquier ruta bajo /api/** que nadie haya clasificado.

hasAnyRole("OPERARIO", "ADMIN") repetido dos veces es un síntoma de que falta una jerarquía de roles: un ADMIN debería poder hacer todo lo de un OPERARIO sin enumerarlo. Lo resolveremos en 05-03 con RoleHierarchy.

Para probar las reglas necesitamos usuarios con roles, y hasta 05-03 no tendremos base de datos de credenciales. InMemoryUserDetailsManager es un UserDetailsService (05-01) que guarda los usuarios en un mapa:

Tres puntos importantes. .roles("CIUDADANO") añade el prefijo ROLE_ automáticamente: escribir .roles("ROLE_CIUDADANO") produce ROLE_ROLE_CIUDADANO y lanza una excepción al arrancar; para autoridades sin prefijo existe .authorities("estaciones:escribir"). User.withDefaultPasswordEncoder() está obsoleto y no debe usarse ni siquiera en ejemplos: anima a dejar contraseñas en el fuente. Y estas contraseñas son ficticias y solo valen en local: en un proyecto real se leerían de variables de entorno. Es andamiaje que desaparecerá en 05-03.

Con esto ya se pueden probar las reglas del apartado 6:

Esos cuatro códigos son la demostración de que la configuración funciona: 200 público, 401 sin identidad, 403 con identidad insuficiente y 200 con el rol correcto.

La regla es absoluta: una contraseña jamás se almacena de forma que pueda recuperarse. Ni en claro, ni cifrada con una clave que esté en el mismo sistema. Se almacena un hash, y solo se comparan hashes.

Y no vale cualquier hash. MD5 y SHA-256 se diseñaron para ser rápidos, que es justo lo contrario de lo que hace falta aquí: una GPU actual calcula del orden de miles de millones de SHA-256 por segundo, así que un diccionario de contraseñas frecuentes se prueba entero en minutos. Las funciones adecuadas son deliberadamente lentas y llevan sal (un valor aleatorio por contraseña, que impide precalcular tablas y hace que dos usuarios con la misma contraseña tengan hashes distintos).

CicloUrbana elige BCrypt: es el valor por defecto de Spring Security, no necesita dependencias extra, tiene veinticinco años de escrutinio público y su coste es ajustable.

Esa fábrica devuelve un DelegatingPasswordEncoder, y merece la pena entender por qué no devolvemos directamente un BCryptPasswordEncoder. Un hash producido por el delegador tiene este aspecto:

El prefijo entre llaves identifica el algoritmo con el que se codificó esa contraseña. Gracias a él, el sistema puede verificar contraseñas antiguas con {pbkdf2} mientras codifica las nuevas con {bcrypt}, y migrar de algoritmo sin obligar a nadie a cambiar su contraseña. Es la razón de que este sea el codificador recomendado incluso en proyectos nuevos: hoy no necesitas migrar, pero dentro de cinco años sí.

El error clásico. Si en la base de datos hay un hash sin prefijo —migrado de un sistema anterior—, el delegador no sabe qué algoritmo aplicar y lanza IllegalArgumentException: There is no PasswordEncoder mapped for the id "null". Hay dos salidas: la correcta a largo plazo es prefijar los hashes existentes con una migración Flyway (UPDATE usuarios SET contrasena_hash = '{bcrypt}' || contrasena_hash); la alternativa es indicar al delegador qué hacer cuando falta el prefijo:

El factor de coste. new BCryptPasswordEncoder(12) indica el exponente del número de iteraciones: cada unidad duplica el trabajo. El valor por defecto es 10; la recomendación actual está entre 10 y 12, y el criterio práctico es elegir el mayor coste cuya verificación siga por debajo de unos 250 ms en tu hardware de producción. Es un equilibrio explícito: subirlo encarece el ataque por fuerza bruta, pero también encarece cada inicio de sesión legítimo y puede convertirse en un vector de denegación de servicio si alguien lanza miles de logins.

Dos consejos finales: codificar es lento a propósito, así que hazlo solo al registrar y al validar, nunca en un bucle; y nunca registres una contraseña en claro en un log, ni siquiera depurando (05-05).

formLogin admite personalización completa —loginPage("/entrar"), successHandler(...)— y es la opción correcta para una aplicación con vistas en el servidor. CicloUrbana desactivará ambos en 05-04, y conviene entender por qué. Form login devuelve una redirección HTTP 302 a una página HTML: una aplicación móvil que espera JSON no sabe qué hacer con eso. HTTP Basic obliga a que el cliente guarde la contraseña del usuario para enviarla en cada petición, lo cual es exactamente lo que un token evita: con JWT, la contraseña se envía una sola vez y lo que se almacena después es un token caducable y revocable. Hasta entonces, mantenemos httpBasic porque hace muy cómodo probar con curl.

CSRF (Cross-Site Request Forgery) es un ataque que abusa de una propiedad del navegador: las cookies se envían automáticamente a su dominio, venga la petición de donde venga.

La defensa es un token impredecible que el servidor entrega y que el cliente debe reenviar en cada petición que modifique estado. El sitio malicioso no puede leerlo, porque la política del mismo origen del navegador se lo impide.

Spring Security lo activa por defecto para POST, PUT, PATCH y DELETE (los métodos seguros e idempotentes de lectura no lo necesitan, 03-03). Es lo que produjo el 403 del ejercicio 3 de 05-01.

¿Se puede desactivar en CicloUrbana? Sí, pero solo bajo condiciones estrictas, y hay que enunciarlas porque csrf.disable() es la línea que más se copia sin entender de todo Spring Security:

El razonamiento, en una frase: CSRF explota que el navegador envía la credencial sola; si la credencial va en una cabecera que solo el código de tu propia aplicación puede añadir, el ataque no tiene con qué operar.

Advertencia importante. Si más adelante CicloUrbana almacenase el JWT en una cookie —una opción legítima que veremos en 05-04— la condición se rompe: la cookie sí viaja sola y CSRF vuelve a ser necesario. Desactivarlo entonces sería una vulnerabilidad real. La decisión de desactivar CSRF depende de dónde vive la credencial, no de que la API sea REST.

Si hiciera falta mantenerlo activo con un cliente JavaScript, la configuración habitual es publicar el token en una cookie legible con .csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())).

Con STATELESS, cada petición debe autenticarse por sí misma. No hay cookie de sesión, el SecurityContext no se guarda entre peticiones y todo lo que el servidor sabe del usuario procede de la credencial que acaba de recibir. Es exactamente la restricción stateless de REST que estudiamos en 03-01, aplicada a la seguridad.

Tres consecuencias:

1. Escala horizontalmente sin esfuerzo: cualquier instancia atiende cualquier petición, sin sesión pegajosa ni replicación. Importará en el módulo 7.
2. CSRF deja de ser necesario (con las condiciones del apartado 10), y HTTP Basic sigue funcionando, porque envía credenciales en cada petición.
3. No hay «cerrar sesión» en el servidor: no hay nada que invalidar. El problema se trata en 05-04.

En 03-02 escribimos ConfiguracionCors como un WebMvcConfigurer. Ese componente actúa dentro del DispatcherServlet, y ahora hay filtros de seguridad delante. El resultado es un fallo desconcertante: la petición OPTIONS de sondeo (preflight) que el navegador envía antes de un POST no lleva credenciales —la especificación lo prohíbe—, así que la seguridad la rechaza con 401 antes de que la configuración CORS llegue a responder. El navegador informa entonces de un error de CORS que en realidad es un error de autenticación.

La solución es una línea:

Le dice a Spring Security que registre su CorsFilter dentro de la cadena de seguridad, en una posición anterior a la autorización, usando el CorsConfigurationSource que haya en el contexto. Para que lo encuentre, conviene publicar la política CORS como bean en lugar de solo como WebMvcConfigurer:

Dos añadidos respecto a 03-02: Authorization entre las cabeceras permitidas, sin la cual el navegador no dejaría enviar el token, y X-Traza-Id expuesta, para mostrar el identificador de traza de 03-06 cuando algo falle. Y la regla de siempre, ahora más importante: nunca * en los orígenes junto con credenciales. El endurecimiento de CORS por entorno se completa en 05-05.

Spring Security añade por defecto un conjunto de cabeceras que instruyen al navegador. No cuestan nada y evitan familias enteras de ataques.

Ajustarlas:

HSTS es una decisión con efectos duraderos: una vez que un navegador recibe la cabecera, se niega a hablar por HTTP con ese dominio durante el plazo indicado. Si activas includeSubDomains con un año y algún subdominio no tiene certificado válido, queda inaccesible y no hay forma de revertirlo desde el servidor. Empieza con un maxAge pequeño. Una API JSON pura no necesita CSP —no sirve HTML—, pero cuesta poco y protege las páginas que el propio Spring sirva, como el Swagger UI de 03-07.

Un mismo proyecto suele tener zonas con reglas incompatibles. En CicloUrbana serán tres: la API (sin estado, con tokens), Actuator (07-01, con su propia política) y los recursos de documentación en desarrollo.

Tres reglas que evitan horas de desconcierto:

1. securityMatcher decide a qué peticiones aplica la cadena; requestMatchers, dentro de authorizeHttpRequests, decide qué permiso hace falta. Confundirlos es constante.
2. Solo se aplica la primera cadena que coincide (05-01). Las demás no se consultan, aunque tengan reglas más específicas.
3. El menor @Order gana, y la cadena sin securityMatcher coincide con todo, así que debe llevar el @Order más alto. Si por error quedara la primera, ninguna otra se ejecutaría jamás.

En el arranque, con el log de FilterChainProxy en DEBUG, se comprueba de un vistazo que el orden es el previsto.

Dos herramientas resuelven el noventa por ciento de los problemas.

El log de depuración:

Con eso, cada petición deja un rastro que indica qué filtro la atendió y, sobre todo, cuál la rechazó:

Esa última línea contiene la respuesta completa: la expresión que falló y el resultado. Nunca hay que adivinar.

El volcado de la cadena, con @EnableWebSecurity(debug = true) —solo en desarrollo—, imprime al arrancar la lista ordenada de filtros de cada cadena y, en cada petición, un resumen del contexto de seguridad.

Advertencia. Ambas opciones vuelcan información sensible: rutas, roles, y en el modo debug también cabeceras que pueden contener credenciales. Jamás deben activarse en producción. Su sitio es application-dev.yml, y los perfiles que garantizan esa separación se estudian en 07-02.

Poner la regla general antes que la específica. El error número uno del módulo. requestMatchers("/api/**").permitAll() en la primera línea abre toda la API y no genera ningún aviso.

Olvidar anyRequest() al final. Sin él, cualquier ruta no clasificada queda sin regla. Termina siempre con denyAll() o authenticated().

Escribir .roles("ROLE_ADMIN"). Produce ROLE_ROLE_ADMIN. Con roles, sin prefijo; con authorities, con prefijo.

Desactivar CSRF «porque es una API». Solo es válido si la credencial no viaja sola en el navegador. Con el token en una cookie, desactivarlo es una vulnerabilidad.

Usar * donde hacía falta **. /api/v1/usuarios/* no cubre /api/v1/usuarios/7/alquileres.

Declarar dos beans SecurityFilterChain sin @Order, o dejar la cadena sin securityMatcher la primera. En el primer caso el orden es arbitrario; en el segundo, esa cadena coincide con todo y anula las siguientes.

Consejo: escribe primero la tabla de accesos, después el código. El apartado 6 se decidió en una tabla que el ayuntamiento podría revisar, y traducirla a código fue mecánico; al revés, la configuración acaba siendo un montón de reglas que nadie sabe justificar. Y prueba cada regla con curl -w '%{http_code}': cuatro comandos confirman que la política es la que crees. En 06-04 automatizaremos estas comprobaciones.

Esta configuración tiene cuatro problemas de seguridad o de funcionamiento. Encuéntralos, explica el impacto de cada uno y reescríbela correctamente.

Escribe la cadena de seguridad de CicloUrbana que cumpla estos requisitos, y justifica cada decisión:

• /api/v1/estaciones en GET: público. Cualquier escritura sobre estaciones: ADMIN.
• Todo /api/v1/alquileres/**: autenticado.
• /api/v1/bicicletas/** en GET: autenticado; escritura: OPERARIO o ADMIN.
• /swagger-ui/** y /v3/api-docs/**: público solo en el perfil dev.
• Cualquier otra ruta bajo /api/**: denegada.
• Sin estado, sin CSRF, con CORS y HTTP Basic.

Un compañero informa de que POST /api/v1/estaciones responde 403 con las credenciales de [email protected], que es ADMIN. Enumera cinco causas posibles y describe cómo distinguirlas con el log de depuración.

Solución 1

Problema 1 — orden invertido: /api/** con permitAll() la primera. Coincide con todo, incluidos usuarios y bicicletas: las dos reglas siguientes son inalcanzables y la API entera queda pública. Es el fallo más grave y el más silencioso.

Problema 2 — hasRole("ROLE_ADMIN") con prefijo. hasRole añade ROLE_, así que la expresión efectiva busca la autoridad ROLE_ROLE_ADMIN, que nadie tiene: la regla nunca concede acceso aunque el orden fuera correcto. Debe ser hasRole("ADMIN") o hasAuthority("ROLE_ADMIN").

Problema 3 — falta anyRequest(). Cualquier ruta no listada —/actuator/**, la consola H2, recursos estáticos— queda sin regla. Debe cerrarse con anyRequest().denyAll().

Problema 4 — csrf.disable() junto a formLogin. Form login usa cookie de sesión, y con la credencial viajando sola en el navegador se cumple exactamente el escenario del ataque CSRF. Aquí desactivarlo es una vulnerabilidad real. Además, formLogin no le sirve a la app móvil de CicloUrbana.

Solución 2

Justificaciones. Las reglas de escritura de estaciones van antes que la de lectura pública, porque GET ... permitAll sobre /api/v1/estaciones/** no captura POST, pero el orden explícito documenta la intención y evita accidentes si alguien amplía el patrón. El GET de bicicletas precede a la regla general de bicicletas, o los ciudadanos no podrían consultar la flota. La documentación se cierra con denyAll() fuera de dev en lugar de simplemente omitirla, porque anyRequest().denyAll() ya la cerraría pero una regla explícita se lee como una decisión, no como un descuido. Y securityMatcher incluye las rutas de Swagger porque, si no, caerían en otra cadena. Una alternativa más limpia a este if es tener dos beans en clases distintas anotadas con @Profile, que es lo que haremos en 07-02.

Solución 3

Causa 1 — CSRF activo. Si csrf.disable() no está y la petición no lleva token, CsrfFilter responde 403 antes de llegar a la autorización. Log: Invalid CSRF token found for .... Es la causa más probable con un POST desde curl.

Causa 2 — orden de reglas. Una regla anterior más general captura la petición y exige otro rol. Log: la expresión que aparece en Failed to authorize no será hasRole('ROLE_ADMIN'), sino la de la regla que realmente se aplicó. Esa discrepancia es el diagnóstico.

Causa 3 — prefijo duplicado. Si la regla es hasRole("ROLE_ADMIN") o el usuario se creó con .roles("ROLE_ADMIN"), la autoridad buscada y la concedida no coinciden. Log: granted=false, expression=hasRole('ROLE_ROLE_ADMIN'), o las autoridades del usuario impresas como [ROLE_ROLE_ADMIN].

Causa 4 — la cadena aplicada no es la que se cree. Con varios beans, securityMatcher puede enviar la petición a otra cadena; el log de FilterChainProxy en TRACE indica el índice de la cadena elegida. Causa 5 — CORS mal integrado: si el 403 solo lo ve un navegador, está fallando el OPTIONS de sondeo por faltar .cors(Customizer.withDefaults()).

El método general, y la lección de la solución: activar DEBUG, lanzar la petición y leer la línea Failed to authorize. Contiene la expresión evaluada y el resultado, y descarta cuatro de las cinco causas de un vistazo.

CicloUrbana ya tiene una política de seguridad escrita y deliberada. Sabes por qué desapareció WebSecurityConfigurerAdapter y por qué el modelo actual —beans SecurityFilterChain en una clase @Configuration normal— compone mejor que la herencia; has creado ConfiguracionSeguridad en el paquete com.ciclourbana.seguridad y entiendes cada pieza: @EnableWebSecurity, el HttpSecurity inyectado como prototipo y el http.build() final que, al declararse, sustituye por completo los valores por defecto de Spring Boot.

Dominas la DSL de lambdas: authorizeHttpRequests con requestMatchers por patrón, por método o por ambos; la diferencia entre * y ** que abre agujeros cuando se confunde; y el catálogo de reglas, de permitAll a denyAll. Sobre todo, has interiorizado la regla de oro: las reglas se evalúan en orden y gana la primera que coincide, así que van de específica a general, anyRequest() cierra siempre la lista y la política sana es la denegación por defecto. Lo has visto fallar en un ejemplo que dejaba públicos los datos personales de todos los ciudadanos de Ribalta sin emitir un solo aviso.

El mapa de accesos está decidido y escrito: estaciones públicas en lectura, alquileres para autenticados, flota e incidencias para operarios, estaciones y usuarios para administradores, documentación solo en desarrollo. Has arrancado con InMemoryUserDetailsManager y tres usuarios de prueba —Marta ciudadana, Luis operario, Ana administradora— y comprobado con curl los cuatro códigos que demuestran que la política funciona: 200 público, 401 sin identidad, 403 con identidad insuficiente y 200 con el rol correcto. Y sabes por qué nunca se almacena una contraseña recuperable, por qué SHA-256 no vale, qué aporta BCrypt con su sal y su factor de coste, y por qué el DelegatingPasswordEncoder y su prefijo {bcrypt} son la elección correcta incluso hoy que no necesitas migrar nada.

Has tomado además las cuatro decisiones de carácter con criterio propio: CSRF desactivado, pero solo tras enunciar las cinco condiciones que lo hacen seguro y con la advertencia de que un token en cookie las rompe; sesión STATELESS, coherente con la restricción REST de 03-01; CORS integrado en la cadena con cors(Customizer.withDefaults()) y un CorsConfigurationSource que ya permite la cabecera Authorization; y las cabeceras de seguridad, con la advertencia sobre lo irreversible que es un HSTS mal calibrado. Sabes separar zonas con @Order y securityMatcher, y depurar con el log de org.springframework.security sin llevarlo jamás a producción.

Queda, sin embargo, el problema evidente: los usuarios viven en un mapa en memoria. Marta, Luis y Ana desaparecen en cada reinicio, sus contraseñas están escritas en el código, nadie puede registrarse y el Usuario que persiste en la tabla usuarios de PostgreSQL —con su correo, su tipo de tarifa y su fecha de alta— no tiene ninguna relación con el usuario que se autentica. Son dos mundos separados. En 05-03, Autenticación y Autorización de Usuarios, los uniremos: ampliaremos la entidad Usuario con credenciales y roles mediante la migración V4, implementaremos un UserDetailsService propio que cargue por correo, crearemos un UsuarioAutenticado que conserve el id, registraremos el DaoAuthenticationProvider, abriremos el endpoint de registro de ciudadanos y haremos que POST /api/v1/alquileres deje de fiarse del usuarioId que envíe el cliente. Las llaves de Ribalta dejarán de estar escritas en el código.