CORS Security Deep Dive

Overview

Cross-Origin Resource Sharing (CORS) errors are among the most frustrating to diagnose because they masquerade as server authentication failures. In Spring Boot 3 / Spring Security 6, CORS must be configured at the Security Filter Chain level — not just via @CrossOrigin or WebMvcConfigurer. If Spring Security intercepts the OPTIONS preflight request before your application code runs, the browser reports a CORS violation regardless of your MVC configuration.

1. 01

   Define a CorsConfigurationSource @Bean and reference it in your SecurityFilterChain via http.cors(cors -> cors.configurationSource(...)).

2. 02

   Never configure CORS in WebMvcConfigurer only — it runs after Spring Security and will not protect preflight requests.

3. 03

   List specific origins explicitly in production; never use the wildcard '*' with allowCredentials(true) — the browser rejects it.

4. 04

   Set allowedHeaders explicitly, including 'Authorization' and 'Content-Type' — the default allowedHeaders is empty.

5. 05

   Use setMaxAge(3600L) to cache preflight responses in the browser and eliminate redundant OPTIONS round-trips.

// ✅ SPRING SECURITY 6 — COMPLETE CORS SETUP
class="hi-ann">@Configuration
class="hi-ann">@EnableWebSecurity
public class SecurityConfig {

    class="hi-ann">@Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            // 1. Wire CORS before any auth checks
            .cors(cors -> cors.configurationSource(corsConfigurationSource()))
            .csrf(csrf -> csrf.disable())  // Use stateless JWT or CSRF tokens separately
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(HttpMethod.OPTIONS, "/**").permitAll() // Explicit preflight permit
                .anyRequest().authenticated()
            );
        return http.build();
    }

    class="hi-ann">@Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration config = new CorsConfiguration();
        
        // Explicit origins only — never "*" with credentials
        config.setAllowedOrigins(List.of(
            "https://app.example.com",
            "https://admin.example.com"
        ));
        
        config.setAllowedMethods(List.of("GET","POST","PUT","PATCH","DELETE","OPTIONS"));
        config.setAllowedHeaders(List.of("Authorization","Content-Type","X-Requested-With"));
        config.setExposedHeaders(List.of("X-Total-Count","Location"));
        config.setAllowCredentials(true);
        config.setMaxAge(3600L); // Cache preflight 1 hour
        
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return source;
    }
}

# application.yml — Environment-specific origins
cors:
  allowed-origins:
    - https://app.example.com
  # dev profile overrides:
  # allowed-origins:
  #   - http://localhost:3000

1. 01

   Externalize allowed origins to environment configuration — never hardcode https://localhost in your production security config.

2. 02

   Add an integration test using MockMvc that sends an OPTIONS request and asserts the correct Access-Control-Allow-Origin header.

3. 03

   Pair CORS with a strict Content-Security-Policy header to prevent XSS-based CORS bypass attacks.

What causes CORS Security Deep Dive in Spring Boot 3?

Browsers send a preliminary OPTIONS request (preflight) before any non-simple cross-origin request. Spring Security evaluates this OPTIONS request against your security rules first. Unless you explicitly permit unauthenticated OPTIONS requests, Spring Security returns 401 or 403 — which the browser interprets as a CORS failure, even though it's actually an authentication failure. The solution requires wiring CORS configuration directly into the SecurityFilterChain.

How do I fix CORS Security Deep Dive?

Define a CorsConfigurationSource @Bean and reference it in your SecurityFilterChain via http.cors(cors -> cors.configurationSource(...)). Never configure CORS in WebMvcConfigurer only — it runs after Spring Security and will not protect preflight requests. List specific origins explicitly in production; never use the wildcard '*' with allowCredentials(true) — the browser rejects it. Set allowedHeaders explicitly, including 'Authorization' and 'Content-Type' — the default allowedHeaders is empty. Use setMaxAge(3600L) to cache preflight responses in the browser and eliminate redundant OPTIONS round-trips.

Best practice #1 for preventing Security · HTTP errors?

Externalize allowed origins to environment configuration — never hardcode https://localhost in your production security config.

Best practice #2 for preventing Security · HTTP errors?

Add an integration test using MockMvc that sends an OPTIONS request and asserts the correct Access-Control-Allow-Origin header.

Best practice #3 for preventing Security · HTTP errors?

Pair CORS with a strict Content-Security-Policy header to prevent XSS-based CORS bypass attacks.