Refine CORS documentation for wildcard processing

[lowcasz]

In CORS configuration we don't have access for request and response, e.g. by servlet filter
We have allowedOriginsPattern to override * wildcard when we are using allowCredentials=true
In this situation we overwrite allowed-origin header by request origin, but heders and methods are still not overwrite wildcard which is not allowed by documentation when we allow credentials.

When some configuration for requestHeaders, exposedHeaders, allowedMethods is null then all is clear,
but when we have allowed credentials and some list is defined with one value with asterisk then it should be overwritten according to CORS documentation.

It is problematically for preflighted requests when we don't know all request headers or exposed headers,
but in single request it should be overwritten according to headers from request and response when we allow credentials,
or we should have possibility to calculate cors headers dynamically based on request and response to fix it manually.

[bclozel]

From the description of this issue, it's not clear whether you are reporting a bug, requesting an enhancement, or asking a question.

Can we take a step back and start over with:

• what are you trying to achieve
• what have you tried (a code snippet of the CORS configuration you are using)
• what's the behavior your are getting
• what behavior you were expecting itself

You can read up good advice on how to create a minimal sample if this is a better option for you.

[lowcasz]

What am I trying to achieve?

• I want extend default CORS configuration to pass everything with any origin, method, requestHeaders, exposedHeaders, allowedCredentials.

What am I tried?
cors-demo.zip

@Configuration
@EnableWebMvc
@RequiredArgsConstructor
public class CorsConfig implements WebMvcConfigurer {

    private final CorsProperties corsProperties;

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**").combine(corsProperties.applyPermitDefaultValues());
    }

}

package example;

import static java.util.Objects.isNull;
import static org.springframework.util.CollectionUtils.isEmpty;

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.web.cors.CorsConfiguration;

@ConfigurationProperties("cors")
public class CorsProperties extends CorsConfiguration {

    @Override
    public CorsConfiguration applyPermitDefaultValues() {
        if (isEmpty(getAllowedOrigins()) && isEmpty(getAllowedOrigins())) {
            addAllowedOriginPattern(ALL);
        }
        if (isEmpty(getAllowedMethods())) {
            addAllowedMethod(ALL);
        }
        if (isEmpty(getAllowedHeaders())) {
            addAllowedHeader(ALL);
        }
        if (isEmpty(getExposedHeaders())) {
            addExposedHeader(ALL);
        }
        if (isNull(getMaxAge())) {
            setMaxAge(1800L);
        }
        if (isNull(getAllowCredentials())) {
            setAllowCredentials(true);
            //todo owerwrite "*" (ALL="*") in all fields dynamically based on request and response, when allow credentials
        }
        return this;
    }

}

Whats behaviour am I gets?

What is expected bahaviour?
CORS documentation don't allow * wildcard (in allowOrigin, methods, requestHeaders, exposedHeaders) when allowCredentials is true.
In this situation, when wildcard was declared in configuration, all response headers should contains listed all needed values instead of *, but response header contains *:
Access-Control-Expose-Headers: *
instead of: Access-Control-Expose-Headers: Location

[sdeleuze]

Looks like there is potentially 2 things here:

• A potential bug related to the fact that we are not preventing users to specify * for Control-Allow-Headers, Control-Allow-Methods and Control-Expose-Headers like we do for Origin when credentials are enabled. Both Mozilla documentation related section and WHATWG specs are mentioning that (could have been updated or we missed that, not sure)
• A feature request to manage patterns for allowed methods, request headers, exposed headers like we do for allowed origins (see related Support for pattern based origin cors configuration #25016 issue).

@lowcasz Could you please confirm your are raising both the described potential bug and enhancement request?

[lowcasz]

Sure ;) It can be like that. We are talking about situation when allowCredentials (Access-Control-Allow-Credentials) is true only. Without credentials actual version is ok.