Contenido del curso
Configuración de seguridad
- 5

Configuración de Seguridad con Spring Security y Basic Authentication
06:32 min - 6

Cómo funciona el BasicAuthenticationFilter por dentro
11:50 min - 7

Deshabilitar CSRF en Spring Security con JWT
07:28 min - 8

Configuración global de CORS en Spring
Viendo ahora - 9

Configuración de Reglas de Acceso en Spring Security
07:45 min - 10

Creación de usuarios personalizados en Spring Security
07:06 min - 11

Creación y Gestión de Roles y Permisos en Aplicaciones Web
05:48 min
Autenticación con BD
Seguridad con JWT
Próximos pasos
Configuración global de CORS en Spring
Resumen
Cuando construyes una API en Spring que será consumida por un frontend en otro dominio o puerto, necesitas configurar CORS (Cross-Origin Resource Sharing) para evitar que el navegador bloquee las peticiones por políticas de seguridad. Aquí aprendes a habilitarlo con Spring Security, tanto a nivel de controlador como de manera global, para que tu API acepte llamados desde frontends como Angular o React sin problemas.
Qué es CORS y por qué Spring lo bloquea por defecto
CORS es un mecanismo del navegador que controla qué orígenes pueden consumir los servicios de tu backend. Spring, por seguridad, bloquea cualquier petición que venga de un dominio o puerto diferente al de tu API.
Imagina que tu frontend en Angular corre en localhost:4200 y tu backend Spring en localhost:8080. Aunque ambos estén en tu máquina, el navegador los considera dos orígenes distintos y rechaza la comunicación con un error claro en consola: blocked by CORS policy.
¿Qué es CORS en Spring Boot? Es un sistema que permite a tu backend decidir qué peticiones desde otros orígenes acepta. Sin esta configuración, el navegador bloquea cualquier llamado entre dominios distintos. [01:00]
Cómo habilitar CORS desde Spring Security
El primer paso es decirle a Spring Security que permita procesar peticiones de orígenes cruzados. Para eso, dentro de tu cadena de configuración de seguridad, después de deshabilitar el csrf, agregas el método cors() y lo enlazas con authorizeHttpRequest usando and.
Con esto activas la puerta de entrada, pero todavía falta indicar qué orígenes específicos vas a permitir y bajo qué reglas. Y aquí viene lo interesante: tienes dos caminos para hacerlo.
Cómo usar la anotación @CrossOrigin en un controlador
La forma más rápida es anotar un método o clase del controlador con @CrossOrigin e indicar el origen permitido. Por ejemplo, en un PizzaController que devuelve las pizzas disponibles:
java @CrossOrigin(origins = "http://localhost:4200") @GetMapping("/pizzas") public List<Pizza> getAvailable() { ... }
Con esa anotación, ese endpoint sabe que debe aceptar peticiones desde localhost:4200. Funciona, pero tiene un problema: si tu API tiene decenas de controladores, anotar cada uno se vuelve tedioso y difícil de mantener. [04:30]
Cómo crear una configuración global de CORS con CorsConfigurationSource
La solución elegante es centralizar las reglas en una clase de configuración. Creas una clase llamada CorsConfig dentro del paquete web.config, la anotas con @Configuration y expones un Bean de tipo CorsConfigurationSource.
Dentro del método defines tres reglas clave:
setAllowedOrigins: lista los dominios permitidos, por ejemplohttp://localhost:4200.setAllowedMethods: define los verbos HTTP aceptados como GET, POST, PUT y DELETE.setAllowedHeaders: indica qué encabezados se aceptan; con un asterisco*permites todos.
Luego registras esa configuración para todos los endpoints usando un UrlBasedCorsConfigurationSource con el patrón comodín que aplica a cualquier ruta del proyecto.
java @Configuration public class CorsConfig { @Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration corsConfiguration = new CorsConfiguration(); corsConfiguration.setAllowedOrigins(Arrays.asList("http://localhost:4200")); corsConfiguration.setAllowedMethods(Arrays.asList("GET","POST","PUT","DELETE")); corsConfiguration.setAllowedHeaders(Arrays.asList("*")); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", corsConfiguration); return source; } }
Así, todos los controladores heredan las mismas reglas sin necesidad de anotaciones individuales. [06:30]
Cómo verificar que CORS funciona en el navegador
Una vez levantado el backend, recargas el frontend en localhost:4200. Si todo está bien configurado, la petición ya no se bloquea por política de origen cruzado.
Es posible que veas un error 401, pero ese ya no es un problema de CORS sino de autenticación. Spring Security genera una contraseña en cada arranque que debes incluir en el header Authorization como Basic Auth. Puedes copiarla desde Postman para obtener el valor codificado y pegarlo en tu frontend.
¿Cuál es la diferencia entre @CrossOrigin y CorsConfigurationSource?
@CrossOriginconfigura un controlador o método específico.CorsConfigurationSourcedefine reglas globales para toda la API desde una sola clase, ideal para proyectos con muchos endpoints.
¿Por qué aparece error 401 después de configurar CORS? Porque Spring Security exige autenticación. CORS solo resuelve el bloqueo de origen; las credenciales se manejan aparte con el header Authorization.
Buenas prácticas al configurar orígenes y métodos permitidos
Algunos detalles que vale la pena cuidar al usar CorsConfigurationSource:
- Especifica orígenes concretos en producción en vez de usar comodines, para reducir superficie de ataque.
- Limita los métodos HTTP a los que tu API realmente expone.
- Usa
*en headers solo en desarrollo; en producción enumera los que necesitas. - Centraliza siempre la configuración en una clase con
@Configurationpara facilitar mantenimiento.
Con esta configuración tu frontend en Angular o React puede consumir tu API Spring sin fricciones, y tú mantienes control sobre qué dominios entran y cuáles no. ¿Has tenido que lidiar con errores de CORS en tus proyectos? Cuéntame en los comentarios cómo los resolviste.