Consider not rejecting preflight requests when no CORS configuration is provided

[rcolombo]

Affects: 3.2.0

---

My project is now getting "403 Invalid CORS Request" responses when sending an OPTIONS request with the "access-control-request-method" header. It worked fine in version 3.1.6.

"access-control-request-method" is a valid CORS header so I'm not sure why this error is surfacing. Two other CORS headers that I use are "origin" and "access-control-request-headers" and they cause no issues. I can send any combination of those two headers and I get the correct responses.

One way around this is to add a custom CorsMapping like such:

@EnableWebMvc
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

  @Override
  public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/**")
        .allowedMethods("*")
        .allowedOrigins("*")
        .allowedHeaders("*");
  }

However, I don't want to do this as I have my own custom CORSInterceptor that I want to handle OPTIONS requests. The above solution does things I don't want, such as setting the response header of access-control-allow-origin: "*"

Did something change that specifically causes issues with just this header?

[bclozel]

Hello @rcolombo - unfortunately, there isn't enough information here to help you. I'm not seeing any specific CORS-related change in the 6.1.x line.

Can you given an example of request that is being rejected? You're also mentioning a custom CORS interceptor and we're not seeing it here. Can you share a minimal sample application that reproduces the problem?

[rstoyanchev]

You could place a debug point in DefaultCorsProcessor, or otherwise provide a minimal sample.

[rcolombo]

Perhaps this is user error. Thank you for pointing me to the DefaultCorsProcessor.

This line rejects my request because I have a preflight request but a null config: https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/cors/DefaultCorsProcessor.java#L85

I'm still unclear why I didn't see this until version 3.2.0 as the DefaultCorsProcessor has been stable for some time. Apologies if this was improperly filed as an issue - there must be something else in my setup that has this working for 3.1.6 and not 3.2.0.

The fix that worked for my exact use case was to implement my CORS Interceptor as a CORS Filter instead. This way, I am able to add CORS response headers before DefaultCorsProcessor processes the request (effectively neutering that processor).

My overall goal is to skip/disable the built-in Spring CORS Processor, as my exact use case requires more complicated processing.

[sdeleuze]

Based on your feedback, I close this issue.

If you want to skip Spring processing, putting a custom CORS filter will indeed likely disable Spring own CORS processing if it sets CORS response headers.

Be aware you also could probably instead provide your own CorsProcessor via org.springframework.web.servlet.handler.AbstractHandlerMapping#setCorsProcessor.

[kenips]

@sdeleuze @rcolombo this is a valid issue even when original poster decided to move away from built-in processor.

The issue stems from https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/cors/DefaultCorsProcessor.java#L96-104:

if (config == null) {
	if (preFlightRequest) {
		rejectRequest(new ServletServerHttpResponse(response));
		return false;
	}
	else {
		return true;
	}
}

where when one does not supply the config, it is assumed that CORS is not enabled and hence you return true. However the block above create a situation where you reject the pre-flight even when config is null. You end up having users reporting issues that only a combination of headers in pre-flight would trigger this, like this here: spring-cloud/spring-cloud-gateway#112.

For my use case, I'd like pre-flight AND actual calls to all route to target server in Spring Cloud Gateway, and the expectation is that I can disable pre-flight rejection here as well. When I start supplying a config to make this work, I ended up having CORS check both at my gateway AND my target app, resulting duplicated Access-Control-Allow-Origin on my final response.

As it currently stands, I also end up rolling my own CorsFilter to allow pre-flight at gateway only, and letting target servers to handle actual.