La lección anterior dejó a CicloUrbana con un agujero que arrastramos desde el principio del módulo. Marta tiene un token válido con el rol ROLE_CIUDADANO, así que su petición POST /api/v1/alquileres/9/finalizar atraviesa la cadena de filtros sin un solo problema: la ruta está permitida a usuarios autenticados y el rol es correcto. Pero el alquiler número 9 es de otro ciudadano de Ribalta. Marta acaba de cerrar el alquiler de un desconocido, y el importe se le ha cobrado a él.

Ninguna regla de authorizeHttpRequests puede impedirlo, porque la respuesta no depende de la ruta ni del rol: depende del dato. Esta lección baja la seguridad hasta la capa donde vive la lógica de negocio, con @EnableMethodSecurity, @PreAuthorize y expresiones SpEL, y después cierra el módulo endureciendo la API completa: CORS por entorno, limitación de tasa, HTTPS obligatorio, ocultación de la documentación en producción, auditoría de eventos, revisión de dependencias vulnerables y una lista de comprobación antes de exponer la red de Ribalta a Internet.

Advertencia que se repetirá al final, porque es la más importante del módulo. Todo lo construido en estas cinco lecciones es un punto de partida didáctico. Antes de exponer un servicio real a Internet, la configuración de seguridad debe ser revisada por un profesional de seguridad y sometida a una auditoría independiente. Los secretos jamás se versionan, y ninguna lista de comprobación sustituye a una prueba de penetración hecha por alguien que no ha escrito el código.

1. Por qué las reglas por URL no bastan
2. @EnableMethodSecurity y sus anotaciones
3. SpEL en las expresiones de seguridad
4. Un evaluador de permisos propio: SeguridadAlquileres
5. @PostAuthorize y @PostFilter: el coste de filtrar tarde
6. Dónde poner las anotaciones: proxies y autoinvocación
7. Endurecimiento de la API
8. Los riesgos OWASP y su mitigación en CicloUrbana
9. Auditoría de eventos de seguridad
10. Dependencias vulnerables
11. Lista de comprobación antes de producción
12. Errores Comunes y Consejos
13. Ejercicios

Las reglas de 05-02 son necesarias y son la primera línea de defensa, pero tienen tres límites estructurales:

No pueden expresar reglas que dependen del dato. «Solo tus propios alquileres» no es una propiedad de la ruta /api/v1/alquileres/9/finalizar: es una relación entre el usuario autenticado y la fila 9 de la tabla. La URL es idéntica sea el alquiler propio o ajeno.

La misma operación se alcanza desde varios sitios. AlquilerService.finalizar lo llama hoy AlquilerController; mañana lo llamará una tarea programada (07-03), un consumidor de mensajes o un endpoint nuevo, y cada punto de entrada es una oportunidad de olvidar la comprobación. Poner la regla en el servicio la aplica una sola vez y para todos.

La protección está lejos de la regla. Quien lee AlquilerService no ve ninguna comprobación y tiene que buscarla en otro fichero, en otro paquete, escrita como un patrón de ruta. La seguridad declarada junto al método que protege es la que se mantiene actualizada.

No son alternativas, son capas. La regla por URL descarta pronto lo que no debe ni llegar; la de método aplica lo que solo se puede decidir con el dato en la mano:

Se activa con una anotación en una clase de configuración:

En Spring Security 6, @EnableMethodSecurity sustituye al antiguo @EnableGlobalMethodSecurity y activa por defecto @PreAuthorize y @PostAuthorize. Sus atributos habilitan los demás: @EnableMethodSecurity(securedEnabled = true, jsr250Enabled = true) añade @Secured y @RolesAllowed.

El criterio: usa @PreAuthorize salvo que tengas una razón concreta. Es la única que combina evaluación temprana con expresiones completas; @Secured y @RolesAllowed solo admiten una lista de roles, lo que ya cubren las reglas por URL; y todo lo que se evalúa después implica que el método ya se ejecutó, con su coste y sus efectos secundarios.

Las expresiones se escriben en SpEL (Spring Expression Language) y disponen de un vocabulario propio:

Ejemplos reales del proyecto:

Esa última expresión es el ejemplo canónico y merece desmenuzarse. #idUsuario se refiere al parámetro del método por su nombre; principal.idUsuario invoca getIdUsuario() sobre el UsuarioAutenticado de 05-03 —aquí se cobra por segunda vez la decisión de crear un UserDetails propio: con el User estándar no habría ningún id que comparar—; y or hasRole('ADMIN') añade la excepción administrativa.

Cuidado con los nombres de parámetro. #idUsuario solo funciona si el compilador conserva los nombres de los argumentos. El spring-boot-maven-plugin activa -parameters por defecto, pero si el proyecto lo pierde, la expresión falla en tiempo de ejecución con un mensaje confuso. La alternativa robusta es @P("idUsuario") sobre el parámetro, o #p0 por posición —menos legible—.

Y una advertencia de fondo: SpEL se evalúa en tiempo de ejecución y no lo comprueba el compilador. Un error tipográfico en hasRole('OPERRARIO') o en principal.idUsuarrio no impide compilar ni arrancar: falla en la primera llamada real, o peor, deniega siempre. Es la razón de que estas expresiones necesiten pruebas automáticas, que es exactamente lo que empieza en el módulo 6.

Volvamos al problema del principio. La regla es: un ciudadano solo puede finalizar sus propios alquileres; un operario o un administrador, cualquiera. Se podría intentar en la anotación:

Esa expresión no se puede probar de forma aislada, no la entiende quien la lee, esconde una consulta a la base de datos dentro de una cadena de texto y no compila nada de lo que hay dentro. La solución idiomática es un bean de seguridad:

Cinco ventajas de esta forma, y son las que la convierten en la recomendada:

1. Es legible. «Es operario o administrador, o es el propietario» se lee de corrido y se puede enseñar al ayuntamiento.
2. Es comprobable. SeguridadAlquileres es un bean normal: se prueba con JUnit y Mockito (06-02, 06-03) sin levantar el contexto de seguridad.
3. Es reutilizable. La misma expresión sirve en obtenerPorId, en cancelar y en cualquier método futuro.
4. Es eficiente. existsByIdAndUsuarioId es una consulta derivada (04-06) que devuelve un booleano; no carga la entidad ni sus relaciones.
5. Concentra el cambio. Si mañana un ciudadano puede gestionar los alquileres de un familiar autorizado, se cambia un método Java, no siete anotaciones.

Nótese el orden de la expresión: hasAnyRole va primero a propósito. SpEL evalúa or en cortocircuito, así que para un operario la consulta a la base de datos ni siquiera se ejecuta.

Y con esto el agujero está cerrado. La petición de Marta sobre el alquiler ajeno ya no llega al cuerpo del método: AccessDeniedException sube por el proxy, ExceptionTranslationFilter la traduce y el AccessDeniedHandler de 05-03 devuelve un 403 con formato ProblemDetail.

Un matiz de diseño. Devolver 403 confirma que el alquiler 9 existe. En un servicio donde la mera existencia sea información sensible, la respuesta correcta es 404: «aquí no hay nada para ti». Para CicloUrbana el 403 es aceptable y más claro; en una aplicación con datos delicados, plantéate el 404.

@PostAuthorize evalúa la expresión después de ejecutar el método, con acceso a returnObject:

Es cómodo cuando el permiso depende de un dato que solo se conoce tras consultar, y tiene dos costes: el método ya se ejecutó, con sus consultas y su tiempo, y cualquier efecto secundario ya ocurrió. De ahí una regla dura: nunca uses @PostAuthorize en un método que escribe. Si realiza un cargo, envía un correo o cambia el estado de una bicicleta, denegar el acceso a posteriori no deshace nada; con @Transactional la excepción sí provoca rollback de la base de datos (04-07), pero no del correo enviado ni de la llamada al proveedor de pagos.

@PostFilter recorre la colección devuelta y elimina los elementos que no pasan la expresión:

El problema es de eficiencia y de escala. Si la red de Ribalta tiene 40 000 alquileres, este método los trae todos, construye 40 000 DTOs y descarta 39 987 en memoria. Y con la paginación de 04-05 el resultado es directamente incorrecto: se pide la página 0 con 20 elementos, el filtro descarta 18 y el ciudadano recibe una página de 2 con un total que miente. La solución correcta es filtrar en la consulta, enlazando con 04-06:

La regla práctica: @PostFilter solo para colecciones pequeñas y acotadas —los cuatro estados de una estación, la lista de tarifas— y nunca sobre resultados paginados. Para todo lo demás, la seguridad forma parte de la consulta.

Las anotaciones van en el servicio, no en el controlador, por tres razones: el servicio es el punto por el que pasan todos los caminos, incluidos los futuros; el controlador se ocupa del transporte HTTP y no de las reglas del negocio; y una regla en el controlador se duplica en cuanto aparece un segundo punto de entrada. Y funcionan exactamente igual que @Transactional (04-07): mediante un proxy que evalúa la expresión antes de delegar en el objeto real. De ahí, tres consecuencias que ya conocemos:

La autoinvocación esquiva la seguridad, igual que esquiva la transacción. Es la misma trampa de 04-07 y aquí es peor, porque el síntoma no es una transacción que no se abre: es una comprobación de permisos que no se ejecuta. Las salidas son las mismas: extraer el método a otro bean —la opción limpia—, inyectar el proxy de sí mismo con @Lazy, o replantear el diseño.

Las otras dos consecuencias del modelo de proxies: los métodos private, static y final no pueden interceptarse —una anotación sobre un método privado se ignora en silencio, sin ningún aviso—, y el bean debe ser gestionado por Spring; un objeto creado con new no tiene proxy ni seguridad.

La seguridad de la aplicación no acaba en la autenticación y la autorización. Estos son los puntos que faltan, cada uno con su configuración concreta.

ConfiguracionCors (03-02) permite http://localhost:5173 para que el frontend del equipo funcione en desarrollo. Ese origen no debe existir en producción.

Dos recordatorios: allowedOrigins("*") junto con allowCredentials(true) está prohibido por la especificación y Spring lo rechaza al arrancar; y CORS no es un mecanismo de seguridad del servidor, sino una política que aplica el navegador —curl la ignora—. Restringir CORS protege a tus usuarios de páginas maliciosas; no protege tu API.

Sin límite de peticiones, un solo cliente puede saturar la API o probar contraseñas sin descanso. Las opciones, de fuera hacia dentro:

La recomendación es limitar en la pasarela y dejar en la aplicación solo las reglas que necesitan contexto, como «cinco intentos de login por minuto y correo». Con Bucket4j:

Tres advertencias. El ConcurrentHashMap no sirve con varias instancias —cada réplica tendría su contador— ni evita crecer sin límite: en producción, Redis (09-02). La clave debe elegirse con cuidado: por IP castiga a todos los usuarios tras una misma NAT; por usuario autenticado es más justo, pero no protege el login, donde aún no hay usuario. Y el estado correcto es 429 con Retry-After, para que el cliente sepa cuándo reintentar.

Un cuerpo enorme o una cabecera monstruosa son una forma barata de denegación de servicio.

max-http-request-header-size merece una nota: el valor por defecto de 8 KB basta de sobra para un JWT de CicloUrbana, pero con tokens grandes de un proveedor externo —con muchos claims— puede quedarse corto y producir un 431 Request Header Fields Too Large difícil de diagnosticar. Súbelo con criterio, no «por si acaso».

Sin TLS, todo el módulo es papel mojado: el token viaja legible por la red y cualquiera en el mismo wifi lo captura. Lo habitual es terminar TLS en el balanceador o el ingress, pero si la aplicación lo hace directamente:

Y para rechazar cualquier petición que llegue sin cifrar, más HSTS (05-02):

Cuando TLS termina en un proxy, la aplicación ve peticiones HTTP y requiresSecure() produciría un bucle de redirecciones. La solución es que el proxy envíe las cabeceras X-Forwarded-* y activar server.forward-headers-strategy: framework.

Cada dato que la API revela sobre sí misma facilita buscar un exploit conocido.

Y la lista de lo que no debe estar accesible en producción:

Todo esto se gobierna con perfiles, el mecanismo que se estudia en 07-02. La regla es que el perfil prod no herede nada peligroso del de desarrollo, y la comprobación práctica es lanzar la aplicación con --spring.profiles.active=prod y verificar que /swagger-ui.html responde 404.

Revisando 03-06 con ojos de seguridad, un error puede regalar información valiosísima: nombres de tablas, rutas del sistema de ficheros, versiones de librerías, la estructura interna del código.

El ManejadorGlobalExcepciones de 03-06 ya lo hace bien: mensajes controlados, código propio y un identificador de traza que permite al soporte encontrar el detalle en el log del servidor, no en la respuesta.

Cerramos el círculo abierto en 05-01, ahora con nombres concretos del proyecto:

Dos observaciones que resumen el módulo. La primera: la mitad de estas mitigaciones no son de Spring Security. Los DTOs de 03-05, las consultas parametrizadas de 04-06 y las restricciones de 04-08 protegen tanto o más que la cadena de filtros. Buena arquitectura y seguridad son en gran medida lo mismo.

La segunda: la inyección SQL merece una nota concreta, porque es el riesgo cuya protección se pierde con más facilidad. Estos dos casos parecen equivalentes y no lo son:

Y hay un detalle que sorprende: el nombre de una columna en un ORDER BY dinámico no se puede parametrizar. Si alguien construye la ordenación concatenando un parámetro de la petición, ahí hay una inyección. La defensa es una lista blanca de columnas ordenables, no un intento de escapado.

Spring Security publica eventos de aplicación en cada intento de autenticación, y escucharlos cuesta muy poco:

Advertencia. Un token o una contraseña en un log es una credencial en un log, y los logs se copian a sistemas de agregación, se envían a terceros y se conservan años. Cuando alguien detecta la fuga, esa credencial lleva meses circulando. Revisa también las librerías: algunos clientes HTTP registran las cabeceras completas en DEBUG.

El tratamiento de logs en profundidad —formato estructurado, agregación, retención— se ve en 09-05, y la alerta automática ante un pico de fallos, en 09-04.

Una aplicación arrastra decenas de dependencias transitivas, y una vulnerabilidad crítica en cualquiera de ellas es una vulnerabilidad de CicloUrbana. OWASP Dependency-Check compara el árbol de dependencias con la base pública de vulnerabilidades:

Cuatro consejos prácticos. Ejecútalo en la integración continua, no a mano, con failBuildOnCVSS para que una vulnerabilidad alta rompa la construcción (módulo 8). Habrá falsos positivos: gestiónalos con un fichero de supresiones documentado, uno por uno y con justificación, nunca bajando el umbral. Actualizar la versión de Spring Boot es la vía más eficaz, porque el starter-parent arrastra decenas de versiones coherentes de golpe, con atención especial a lo que no gestiona, como el JJWT de 05-04. Y suscríbete a los avisos de seguridad de Spring: una vulnerabilidad conocida se explota masivamente a las pocas horas de publicarse.

Advertencia final, y la más importante del módulo. Esta lista es necesaria y no es suficiente. Todo lo construido en estas cinco lecciones es un punto de partida didáctico: cubre los errores más comunes, pero no sustituye a una revisión profesional. Antes de exponer un servicio real —y más si maneja datos personales de ciudadanos, como CicloUrbana— la configuración debe ser revisada por un especialista en seguridad y sometida a una prueba de penetración por alguien que no haya escrito el código. La seguridad no es un estado que se alcanza: es un proceso que se mantiene, con revisiones periódicas, actualizaciones y atención a los avisos.

Poner @PreAuthorize en el controlador. Deja el servicio desprotegido ante cualquier otro punto de entrada: tareas programadas, consumidores de mensajes o un endpoint nuevo.

Anotar un método private o llamarlo desde la propia clase. El proxy no interviene y la comprobación no se ejecuta, sin ningún aviso. Es la trampa de 04-07 con consecuencias peores.

Usar @PostFilter sobre resultados paginados. Rompe la paginación y trae toda la tabla a memoria. Filtra en la consulta.

@PostAuthorize en un método que escribe. El efecto ya ocurrió; el rollback de la transacción no deshace un correo enviado ni un cargo hecho.

Escribir SpEL complejo dentro de la anotación. No se compila, no se prueba y nadie lo entiende: extrae un bean de seguridad. Y recuerda que SpEL no lo comprueba el compilador, así que hasRole('OPERRARIO') arranca sin protestar y deniega siempre; estas expresiones necesitan pruebas (módulo 6).

Confiar en CORS como mecanismo de seguridad. Lo aplica el navegador; curl lo ignora. Y nunca registres tokens ni contraseñas «solo en DEBUG»: los logs se copian y se conservan años.

Consejo: escribe la regla de seguridad y su prueba a la vez. Una regla sin prueba es una hipótesis, y el módulo 6 empieza precisamente por ahí.

Consejo: revisa la seguridad como revisas el código. Un cambio en ConfiguracionSeguridad, en un @PreAuthorize o en un DTO merece la misma atención que un cambio en la lógica de cobro.

IncidenciaService gestiona las averías de la flota de Ribalta. Aplica seguridad de método con estos requisitos, justificando cada anotación:

1. Cualquier ciudadano autenticado puede crear una incidencia sobre una bicicleta.
2. Solo un OPERARIO puede cerrar una incidencia.
3. Un ciudadano puede consultar las incidencias que él mismo creó; un operario, cualquiera.
4. Solo un ADMIN puede borrar una incidencia.
5. El listado paginado debe devolver a cada ciudadano solo las suyas, y a un operario todas.

Esta clase tiene cinco problemas de seguridad. Encuéntralos, explica el impacto de cada uno y reescríbela.

El ayuntamiento va a desplegar CicloUrbana en producción la semana que viene. Redacta el informe de las diez comprobaciones que harías, ordenadas por criticidad, indicando para cada una cómo la verificarías de forma objetiva.

Solución 1

Justificaciones. El punto 1 usa isAuthenticated() y no hasRole('CIUDADANO'), porque un operario también debe poder reportar; y el autor se toma del principal para que nadie pueda crear incidencias a nombre de otro. El punto 3 es la única regla que depende del dato y por eso necesita un bean, SeguridadIncidencias, con la misma forma que SeguridadAlquileres. El punto 5 es el más instructivo: la decisión de qué consulta ejecutar es una decisión de seguridad, y hacerla en la consulta —en lugar de con @PostFilter— es lo único compatible con paginación. El método esOperario() de UsuarioAutenticado encapsula la comprobación de la autoridad ROLE_OPERARIO, que de otro modo se repetiría por todo el proyecto.

Solución 2

Problema 1 — devuelve la entidad Usuario. La respuesta incluye contrasenaHash, los roles y cualquier campo que se añada en el futuro: es exposición excesiva de datos, el fallo que motivó los DTOs de 03-05.

Problema 2 — IDOR en obtener. No hay ninguna comprobación de permiso: cualquiera autenticado —o cualquiera, si la regla por URL fallara— lee la ficha de cualquier ciudadano cambiando el id. Es el riesgo A01/BOLA.

Problema 3 — inyección SQL en buscar. El parámetro nombre se concatena en una consulta nativa. Con nombre = ' OR '1'='1 se devuelven todos los usuarios; con una carga útil más elaborada, se pueden ejecutar otras sentencias.

Problema 4 — @PreAuthorize sobre un método private. El proxy no puede interceptarlo: la anotación se ignora en silencio y el método queda sin protección. Además, un método privado no puede ser un manejador de Spring MVC.

Problema 5 — mass assignment en actualizar. Recibe la entidad completa, así que la petición puede cambiar roles, contrasenaHash, activo o incluso el id. Un ADMIN comprometido —o un error— puede reescribir cualquier campo.

El controlador queda reducido a transporte: tres métodos public que reciben @PathVariable, @RequestParam validados y @Valid @RequestBody ActualizarUsuarioRequest, devuelven UsuarioResponse o PaginaResponse<UsuarioResponse> y delegan en el servicio, donde viven ahora todas las reglas:

ActualizarUsuarioRequest contiene solo nombre y tipoTarifa: ni roles, ni contraseña, ni activo, ni id. Ese es el punto: lo que no está en el DTO no se puede modificar, y el cambio de roles vive en su propio endpoint con sus propias reglas (ejercicio 3 de 05-03).

Solución 3

Criterio de ordenación: primero lo que compromete todo el sistema de golpe (un secreto filtrado, tráfico sin cifrar), después lo que compromete datos de terceros (denegación por defecto, acceso cruzado), luego lo que facilita el ataque (documentación abierta, fugas en errores) y por último lo preventivo. Y una observación sobre la número 1 que se olvida siempre: un secreto que estuvo en un commit y luego se borró sigue estando en el historial de Git, así que borrarlo no basta: hay que rotarlo.

El módulo 5 se cierra con la red de Ribalta protegida de arriba abajo. Has entendido por qué las reglas por URL de 05-02, siendo necesarias, no bastan: no pueden expresar reglas que dependen del dato, no cubren los puntos de entrada que aún no existen y dejan la protección lejos del código que protegen. La seguridad de método es la capa que completa la perimetral, y ahora sabes elegir entre sus anotaciones con criterio: @PreAuthorize como opción por defecto, @PostAuthorize solo cuando el permiso depende del resultado y nunca sobre métodos que escriben, @PostFilter prácticamente nunca —porque trae toda la tabla a memoria y rompe la paginación de 04-05— y @Secured o @RolesAllowed únicamente en código heredado. Dominas el vocabulario SpEL —hasRole, principal, #parametro, @bean.metodo(...)— y su gran advertencia: no lo comprueba el compilador, así que una regla mal escrita arranca sin protestar y deniega siempre.

Has cerrado el agujero con el que empezaba este módulo mediante SeguridadAlquileres.esPropietario, un bean legible, comprobable, reutilizable y eficiente, y sabes que las anotaciones viven en el servicio y funcionan con proxies, con la misma trampa de autoinvocación de @Transactional y una consecuencia peor: la comprobación que no se ejecuta no avisa. Y has endurecido la API punto por punto: CORS sin localhost en producción y sin la ilusión de que CORS proteja el servidor, limitación de tasa con 429 y Retry-After, tamaños máximos de petición, HTTPS obligatorio con HSTS y X-Forwarded-*, Swagger y Actuator cerrados fuera de desarrollo, errores que no filtran nada, la tabla OWASP con la mitigación concreta de cada riesgo —incluida la nota sobre el ORDER BY dinámico que ningún parámetro puede proteger—, la auditoría de eventos con su lista de lo que jamás se registra, la revisión de dependencias con Dependency-Check y una lista de veinte comprobaciones cuyo último punto es el más importante: esto es un punto de partida didáctico y necesita la revisión de un profesional de seguridad y una auditoría independiente antes de exponerse a Internet.

CicloUrbana tiene por fin puertas, cerraduras y un registro de quién entra por cada una. Pero hay una pregunta incómoda que atraviesa todo lo construido y que hasta ahora hemos respondido con curl y buena voluntad: ¿cómo sabemos que funciona? Nadie ha comprobado automáticamente que un ciudadano no pueda finalizar el alquiler de otro, que anyRequest().denyAll() cierre de verdad lo que creemos, que el token caduque a los quince minutos o que la migración V4 deje el esquema como esperamos. Cada cambio futuro —un @PreAuthorize retocado, una regla reordenada, una dependencia actualizada— puede romper en silencio cualquiera de esas garantías, y lo descubriríamos en producción. El módulo 6, Pruebas en Spring Boot, resuelve eso: veremos la pirámide de pruebas y qué merece probarse, escribiremos pruebas unitarias con JUnit 5 y dobles con Mockito, pruebas de integración con @SpringBootTest, @WebMvcTest y @DataJpaTest —incluidas las de seguridad con @WithMockUser, que convertirán en asertos automáticos cada regla de este módulo— y levantaremos un PostgreSQL real y efímero con Testcontainers para comprobar que Flyway, las entidades y las consultas se comportan igual que en Ribalta. La red de Ribalta está protegida; ahora hay que demostrarlo.