spring-boot: Broken CORS Support with Spring Security

Since Spring Security 4.1, this is the proper way to make Spring Security support CORS (also needed in Spring Boot 1.4/1.5):

@Configuration
public class WebConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedMethods("HEAD", "GET", "PUT", "POST", "DELETE", "PATCH");
    }
}

and:

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
//        http.csrf().disable();
        http.cors();
    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        final CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(ImmutableList.of("*"));
        configuration.setAllowedMethods(ImmutableList.of("HEAD",
                "GET", "POST", "PUT", "DELETE", "PATCH"));
        // setAllowCredentials(true) is important, otherwise:
        // The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
        configuration.setAllowCredentials(true);
        // setAllowedHeaders is important! Without it, OPTIONS preflight request
        // will fail with 403 Invalid CORS request
        configuration.setAllowedHeaders(ImmutableList.of("Authorization", "Cache-Control", "Content-Type"));
        final UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);
        return source;
    }
}

Do not do any of below, which are the wrong way to attempt solving the problem:

• http.authorizeRequests().antMatchers(HttpMethod.OPTIONS, "/**").permitAll();
• web.ignoring().antMatchers(HttpMethod.OPTIONS);

Reference: http://docs.spring.io/spring-security/site/docs/4.2.x/reference/html/cors.html

If you want to define CORS configuration in a single place and get it used by both Spring MVC and Spring Security, the filter based solution is indeed a good one. In that case, don’t use @CrossOrigin at @Controller or @RequestMappinglevel and just configure a global filter that will handle both Spring Security and Spring MVC requests. Be aware that you don’t have to create your own filter, we provide one with Spring Framework, based on the same logic than the @CrossOrigin support.

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("http://domain1.com);
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    source.registerCorsConfiguration("/**", config);
    Filter corsFilter = new CorsFilter(source);

In order to get this filter taken in account, you can use it with Spring Security addFilterBefore() method like you did, or register it as a @Bean. There may be an order issue if your register a CorsFilter bean so currently you need to register a FilterRegistrationBean bean to be able to specify the order:

@Bean
public FilterRegistrationBean corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("http://domain1.com");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    source.registerCorsConfiguration("/**", config);
    FilterRegistrationBean bean = new FilterRegistrationBean(new CorsFilter(source));
    bean.setOrder(0);
    return bean;
}

That said, for your use case there is maybe an improvement we discussed with @dsyer: supporting @CrossOrigin annotation with a global scope if used at @Configuration level. That could result is creating a filter with order = 0 like explained previously, but in a much more concise way for the user. This improvement + more guideline in the documentation in order to advise to use global CORS configuration for secured websites would resolve this kind of issue I think. This kind of feature may also be useful for enabling CORS on Spring Data REST. Any thoughts?

If there is no way around, I would suggest to remove these Annotations if Spring Technologies dont support it sufficient. In every web app you need a kind of authentication. What is the benefit of those annotations if you cant use them with spring security and you need to develop your own filter system. Even if you dont need spring security you still need your own implementation of an authentication system that will not work with those annotations I guess.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@rudolfschmidt I wanted to let you know that Spring Security 4.1.1 was released with what should be a fix for the CORS issues you were having. Take a look at the second example which leverages the CORS configuration from Spring MVC http://docs.spring.io/spring-security/site/docs/4.1.x/reference/htmlsingle/#cors

NOTE: You must use Spring Framework 4.3.1 to take advantage of this feature because it is the first release to provide the necessary hooks.

I have updated my Spring + CORS blog post to add more details about the filter based solution: https://spring.io/blog/2015/06/08/cors-support-in-spring-framework#filter-based-cors-support and also answered on Stackoverflow.

I will update it again if we achieve better integration between Spring MVC and Spring Security as suggested by @rstoyanchev.

We are also looking for ways to expose the knowledge that we have with @CrossOrigin at the HandlerMapping level to Spring Security and I’ll provide an update once we know more

In the meantime however as Sebastien pointed out, we do provide a CorsFilter so you can re-use the same infrastructure code that underlies the @CrossOrigin support. In other words you don’t have to write such a Filter yourself.