Cors Wildcard in Spring Boot with Basic Auth

In Spring Boot, a CORS wildcard configuration combined with HTTP Basic Authentication can unintentionally expose authenticated endpoints to any origin. When allowedOrigins("*") is used together with credentials or with pre-flight handling that does not validate the origin, browsers may allow cross-origin requests that include Basic Auth credentials. This can lead to unauthorized cross-origin interactions and information exposure.

Basic Authentication transmits credentials in the Authorization header using a base64-encoded string that is easily decoded. If a frontend served from one origin sends a request with Basic Auth to an API configured with a CORS wildcard, any webpage on any origin could initiate authenticated requests in the user’s browser, provided the user has valid credentials. This violates the same-origin policy intent and can enable cross-origin credential theft or CSRF-like scenarios where authenticated actions are performed unknowingly.

During a scan using the middleBrick web dashboard or CLI (middlebrick scan <url>), such misconfigurations are flagged under the Authentication and Property Authorization checks. The scanner detects a permissive CORS policy alongside the presence of the Authorization header and reports the risk with remediation guidance. The finding includes severity, a reference to relevant OWASP API Top 10 categories, and prioritized steps to tighten CORS in conjunction with authentication mechanisms.

An example of a vulnerable Spring Boot CORS configuration is:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.cors(cors -> cors.configurationSource(request -> {
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedOrigins(List.of("*")); // Vulnerable wildcard
            config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
            config.setAllowedHeaders(List.of("*"));
            config.setAllowCredentials(true); // Dangerous with wildcard origins
            return config;
        }));
        http.httpBasic(Customizer.withDefaults());
        http.authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
        return http.build();
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration auth) throws Exception {
        return auth.getAuthenticationManager();
    }
}

In this configuration, setAllowCredentials(true) with setAllowedOrigins("*") is non-compliant with browser security standards; modern browsers will reject such combinations, but legacy behavior or non-browser clients may still permit dangerous cross-origin authenticated requests. The scanner’s unauthenticated attack surface tests can surface these issues by probing OPTIONS pre-flight responses and inspecting CORS headers alongside authentication mechanisms.

To secure Spring Boot APIs using HTTP Basic Authentication, explicitly define allowed origins instead of using a wildcard. Combine this with proper credential handling and consider mitigating CSRF for state-changing methods. The following code demonstrates a secure CORS and Basic Auth setup.

Use a specific list of origins and avoid enabling credentials for wildcard origins. If your frontend is hosted on a known domain, specify it directly:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Value("${allowed.frontend.origin}")
    private String frontendOrigin;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.cors(cors -> cors.configurationSource(request -> {
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedOrigins(List.of(frontendOrigin)); // Specific origin
            config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
            config.setAllowedHeaders(List.of("Authorization", "Content-Type"));
            config.setExposedHeaders(List.of("X-Request-ID"));
            config.setAllowCredentials(true); // Safe when origins are not "*"
            return config;
        }));
        http.httpBasic(Customizer.withDefaults());
        http.authorizeHttpRequests(auth -> auth
            .requestMatchers(HttpMethod.POST, "/api/**").hasRole("USER")
            .anyRequest().authenticated()
        );
        return http.build();
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration auth) throws Exception {
        return auth.getAuthenticationManager();
    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowedOrigins(List.of(frontendOrigin));
        config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
        config.setAllowedHeaders(List.of("Authorization", "Content-Type"));
        config.setAllowCredentials(true);
        source.registerCorsConfiguration("/api/**", config);
        return source;
    }
}

Additional remediation practices include:

• Always validate the Origin header on the server side if custom logic is required, rather than relying solely on CORS configuration.
• Use short-lived credentials and avoid embedding sensitive information in URLs that may be logged.
• Combine Basic Auth with HTTPS to protect credentials in transit; otherwise base64-encoded credentials can be decoded trivially.
• For SPAs, consider token-based authentication (e.g., OAuth 2.0 with Bearer tokens) to have finer control over scope and revocation.

After applying fixes, rerun the scan using the middleBrick CLI or web dashboard to confirm that CORS headers no longer include a wildcard with allow-credentials and that authentication checks pass. The CLI command middlebrick scan <url> provides per-category breakdowns and prioritized remediation guidance.