Cuando hablamos de seguridad en aplicaciones Spring, no basta con restringir el acceso a los endpoints. A veces necesitas blindar la lógica de negocio para que solo ciertos roles ejecuten métodos específicos. Ahí entra method security de Spring Security, una capa que te permite decidir, a nivel de método, quién puede y quién no.

¿Qué es method security en Spring Security?

Es un mecanismo que protege métodos individuales mediante anotaciones, sin depender solo de la configuración de rutas en el controlador. Te da control fino sobre la lógica de negocio.

¿Para qué sirve method security? Para autorizar la ejecución de un método según el rol del usuario, incluso si la URL del controlador ya permitió el acceso. Es una segunda barrera dentro de tu servicio.

¿Cómo configurar el acceso por roles en SecurityConfig?

Antes de proteger el método, necesitas permitir que tanto el rol admin como el rol customer lleguen al endpoint. En el archivo SecurityConfig defines un nuevo Request Matcher para la ruta /api/customers/** y autorizas ambos roles.

El flujo del ejemplo va así:

• En OrderController existe un método que recupera las órdenes de un cliente.
• Copias ese método al CustomerController y lo renombras como getCustomerOrders.
• Inyectas OrderService mediante private final OrderService en el constructor.
• Ajustas el matcher en SecurityConfig para que /api/customers/** acepte peticiones de admin y customer.

Con eso, un usuario customer autenticado en Postman con credenciales básicas (por ejemplo customer:customer123) ya puede consultar /api/customers/{cedula} y obtener sus órdenes. El problema aparece enseguida: ese mismo usuario podría consultar las órdenes de cualquier otro cliente cambiando la cédula. Y eso, en términos de seguridad, es inaceptable.

¿Cómo se usa la anotación @Secured para proteger un método?

La anotación @Secured se coloca directamente sobre el método del servicio que quieres proteger. Recibe un arreglo de strings con los roles autorizados.

En el ejemplo, el método dentro de OrderService que devuelve las órdenes de un cliente se anota así para que solo el rol admin pueda ejecutarlo:

java @Secured("ROLE_ADMIN") public List<Order> getCustomerOrders(String cedula) { // lógica del método }

Así, aunque la ruta del controlador permita el acceso a customer, el servicio rechaza la ejecución si el usuario no es administrador.

¿Por qué hay que activar @EnableMethodSecurity?

Porque Spring no procesa estas anotaciones por defecto. Tienes que habilitarlo de forma explícita.

En la clase SecurityConfig, debajo de la anotación @Configuration, agregas:

java @EnableMethodSecurity(securedEnabled = true)

El atributo securedEnabled viene en false por defecto. Al ponerlo en true, le dices a Spring que respete las anotaciones @Secured que encuentre fuera de los controladores, por ejemplo en servicios o en cualquier capa de negocio.

¿Dónde puedo poner @Secured? En cualquier bean gestionado por Spring: servicios, componentes o repositorios. No está limitada a controladores, y ese es justamente su valor.

¿Cómo se comprueba el comportamiento en Postman?

La prueba es directa y deja ver la diferencia entre autenticación y autorización a nivel de método.

1. Con un usuario customer autenticado, lanzar la petición a /api/customers/{cedula} devuelve un 403 Forbidden porque el método interno exige rol admin.
2. Con un usuario admin, la misma petición devuelve la lista de órdenes correctamente.
3. El acceso al endpoint sigue permitido para ambos roles, pero la ejecución del método queda restringida.

Ese 403 confirma que la barrera funciona en dos niveles: la configuración de rutas deja entrar al usuario, y la anotación @Secured filtra quién puede ejecutar la lógica.

¿Qué ventajas da proteger la capa de servicio?

Proteger solo controladores deja huecos cuando un servicio es consumido desde múltiples puntos. Llevar la seguridad al servicio te asegura coherencia.

Algunas ventajas concretas:

• Evitas que un endpoint nuevo herede accesos no deseados a métodos sensibles.
• Centralizas las reglas de autorización junto a la lógica de negocio que las necesita.
• Reduces el riesgo de que un cliente consulte datos de otros usuarios cambiando parámetros.
• Permites auditar más fácil quién ejecuta qué dentro del sistema.

En el siguiente paso del proyecto vas a integrar JSON Web Tokens para gestionar la autenticación con tokens en lugar de credenciales básicas. ¿Tú ya usaste @Secured o prefieres @PreAuthorize? Cuéntame en los comentarios.