springspring-bootspring-securitycorscsrf

Spring Security: httpSecurity.cors(Customizer.withDefaults()); vs httpSecurity.cors(AbstractHttpConfigurer::disable); What's the difference?

Cross-Origin Resource Sharing (CORS) being a HTTP-header-based mechanism is, as I understand it, disallowed by default in browsers. Only if a cross-site server application sends the Access-Control-Allow-Origin-header with the original application's domain as its value (or a wildcard like "*") will that original application be given the response to process it, otherwise it will be blocked by CORS policy of the browser.

Neither httpSecurity.cors(Customizer.withDefaults()); nor httpSecurity.cors(AbstractHttpConfigurer::disable); seem to change this behavior as I have found through experiementation (using the codebase of this tutorial): https://medium.com/@sallu-salman/cross-origin-resource-sharing-cors-in-spring-boot-applications-116163a88adc I'm using Spring Security 6.4.2 which comes with SpringBoot's current version 3.4.1.

Is it fair to say that for practical purposes they have the same effect?

I understand that they do different things in the implementation, but from an application developer's point of view, does it matter which to choose? Or to choose neither, since both do not change the default behaviour of not sending an Access-Control-Allow-Origin-header?

I started reading into this after following a youtube-tutorial on Spring Security titled "1. Initial Setup | Spring Security with SB3" https://www.youtube.com/watch?v=mPHbM6o8bk8 in which the author used

http
                .cors(AbstractHttpConfigurer::disable)
                .csrf(AbstractHttpConfigurer::disable)

without explanation. This struck me as odd for several reasons, one of which being that while .cors(AbstractHttpConfigurer::disable) didn't seem to do anything (in particular not altering the browser's default behaviour), .csrf(AbstractHttpConfigurer::disable) on the other hand disables Spring Security's default protection against Cross-Site Request Forgery by disabling the default creation of the CSRF token. Or am I mistaken here? This is the (updated) code of the security configuration:

 @Bean
            public SecurityFilterChain applicationSecurity(HttpSecurity http) throws Exception {
                http
                .cors(AbstractHttpConfigurer::disable)
                .csrf(AbstractHttpConfigurer::disable)
                .securityMatcher("/**") // map current config to given resource path
                .sessionManagement(sessionManagementConfigurer
                        -> sessionManagementConfigurer.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .formLogin(AbstractHttpConfigurer::disable) 
                .authorizeHttpRequests(registry -> registry
                        .requestMatchers("/").permitAll()
                        .anyRequest().authenticated()
                );
                
                return http.build();
            }

For context, the author's goal in the video series is to secure a (by default stateless) REST API, not a Spring MVC dynamic web-application. This is the first step of that endeavor.

Solution