CORS configuration in Security in Spring Boot - Step-by-Step Execution

Concept Flow - CORS configuration in Security

Client sends HTTP request

↓

Server receives request

↓

Spring Security intercepts request

↓

Check CORS configuration

↓

Process request

↓

Send response back to client

This flow shows how a client request is checked against CORS rules in Spring Security before processing or rejecting it.

Execution Sample

Spring Boot

http.cors().and().authorizeRequests()
  .anyRequest().authenticated();

@Bean
CorsConfigurationSource corsConfigurationSource() {
  CorsConfiguration config = new CorsConfiguration();
  config.setAllowedOrigins(List.of("http://example.com"));
  config.setAllowedMethods(List.of("GET", "POST"));
  UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
  source.registerCorsConfiguration("/**", config);
  return source;
}

This code configures Spring Security to allow CORS requests only from http://example.com with GET and POST methods.

Execution Table

Step	Request Origin	Request Method	CORS Allowed?	Action	Response
1	http://example.com	GET	Yes	Process request	200 OK with data
2	http://example.com	POST	Yes	Process request	200 OK with data
3	http://malicious.com	GET	No	Reject request	403 CORS error
4	http://example.com	DELETE	No	Reject request	403 CORS error
5	http://example.com	OPTIONS	Yes	Process preflight	200 OK preflight
6	http://unknown.com	POST	No	Reject request	403 CORS error
7	-	-	-	-	Stop: No more requests

💡 Requests stop being processed when origin or method is not allowed by CORS config.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
allowedOrigins	[]	[http://example.com]	[http://example.com]	[http://example.com]	[http://example.com]	[http://example.com]
allowedMethods	[]	[GET, POST]	[GET, POST]	[GET, POST]	[GET, POST]	[GET, POST]
requestOrigin	-	http://example.com	http://example.com	http://malicious.com	http://example.com	-
requestMethod	-	GET	POST	GET	DELETE	-
corsAllowed	-	true	true	false	false	-

Key Moments - 3 Insights

Why does a request from http://malicious.com get rejected even if the method is GET?

Because the origin http://malicious.com is not in the allowedOrigins list as shown in execution_table row 3, so CORS blocks it.

Why is the OPTIONS method allowed even though it is not explicitly listed in allowedMethods?

OPTIONS is used for CORS preflight requests and is automatically handled by Spring Security when CORS is enabled, as seen in execution_table row 5.

What happens if the request method is DELETE which is not allowed?

The request is rejected with a CORS error because DELETE is not in allowedMethods, shown in execution_table row 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response when the request origin is http://example.com and method is GET?

A 404 Not Found

B 403 CORS error

C 200 OK with data

D 500 Server Error

💡 Hint

Check execution_table row 1 under Response column.

At which step does the CORS check fail due to an unallowed origin?

A Step 2

B Step 3

C Step 5

D Step 1

💡 Hint

Look at execution_table row 3 where requestOrigin is http://malicious.com and CORS Allowed? is No.

If we add "DELETE" to allowedMethods, which step's action would change from reject to process?

A Step 4

B Step 6

C Step 3

D Step 5

💡 Hint

Check execution_table row 4 where method is DELETE and action is reject.

Concept Snapshot

CORS configuration in Spring Security:
- Enable with http.cors() in SecurityFilterChain
- Define allowed origins and methods in CorsConfigurationSource bean
- Spring Security checks origin and method on each request
- Allowed requests proceed, others get CORS error
- OPTIONS requests for preflight handled automatically

Full Transcript

When a client sends a request, Spring Security intercepts it and checks the CORS configuration. It compares the request's origin and method with the allowed origins and methods defined in the CorsConfigurationSource bean. If both match, the request is processed normally and a successful response is sent. If either the origin or method is not allowed, Spring Security rejects the request with a CORS error, preventing unauthorized cross-origin access. OPTIONS requests are treated as preflight checks and allowed automatically if CORS is enabled. This ensures only trusted origins and methods can access the server resources.

Practice

1. What is the main purpose of configuring CORS in a Spring Boot security setup?

easy

A. To control which external websites can access your backend resources

B. To improve database query performance

C. To manage user authentication tokens

D. To style the frontend user interface

Solution

1. Step 1: Understand CORS role in web security

   CORS (Cross-Origin Resource Sharing) controls which external domains can call your backend APIs.

2. Step 2: Identify the purpose in Spring Boot security

   Configuring CORS in Spring Security allows safe cross-site requests by specifying allowed origins and methods.

3. Final Answer:

   To control which external websites can access your backend resources -> Option A

4. Quick Check:

   CORS controls access origins = A [OK]

Hint: CORS = Cross-Origin access control [OK]

Common Mistakes:

• Confusing CORS with authentication
• Thinking CORS improves database speed
• Assuming CORS styles frontend

2. Which of the following is the correct way to enable CORS in a Spring Security configuration class?

easy

A. http.corsEnabled(true);

B. http.enableCors();

C. http.allowCors(true);

D. http.cors().and().csrf().disable();

Solution

1. Step 1: Recall Spring Security CORS enabling syntax

   Spring Security uses the method http.cors() to enable CORS support.

2. Step 2: Identify the correct chaining method

   The correct chaining to disable CSRF and enable CORS is http.cors().and().csrf().disable();

3. Final Answer:

   http.cors().and().csrf().disable(); -> Option D

4. Quick Check:

   Enable CORS with http.cors() = C [OK]

Hint: Use http.cors() to enable CORS in Spring Security [OK]

Common Mistakes:

• Using non-existent methods like enableCors()
• Forgetting to chain with .and()
• Confusing CORS enabling with CSRF

3. Given this Spring Security CORS configuration snippet, what origins are allowed?

@Bean
public CorsConfigurationSource corsConfigurationSource() {
  CorsConfiguration configuration = new CorsConfiguration();
  configuration.setAllowedOrigins(List.of("https://example.com", "https://app.example.com"));
  configuration.setAllowedMethods(List.of("GET", "POST"));
  UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
  source.registerCorsConfiguration("/**", configuration);
  return source;
}

medium

A. No origins are allowed because configuration is incomplete

B. Requests from any origin are allowed

C. Only requests from https://example.com and https://app.example.com are allowed

D. Only GET requests from any origin are allowed

Solution

1. Step 1: Analyze allowed origins list

   The code sets allowed origins explicitly to "https://example.com" and "https://app.example.com".

2. Step 2: Understand effect on requests

   Only requests coming from these two origins will be accepted; others will be blocked by CORS policy.

3. Final Answer:

   Only requests from https://example.com and https://app.example.com are allowed -> Option C

4. Quick Check:

   Allowed origins = example.com and app.example.com = D [OK]

Hint: Allowed origins list controls which sites can call backend [OK]

Common Mistakes:

• Assuming all origins allowed by default
• Confusing allowed methods with allowed origins
• Thinking configuration is incomplete without headers

4. Identify the error in this Spring Security CORS configuration code:

@Bean
public CorsConfigurationSource corsConfigurationSource() {
  CorsConfiguration configuration = new CorsConfiguration();
  configuration.setAllowedOrigins("*");
  configuration.setAllowedMethods(List.of("GET", "POST"));
  UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
  source.registerCorsConfiguration("/**", configuration);
  return source;
}

medium

A. Allowed methods list is missing PUT and DELETE

B. setAllowedOrigins expects a list, not a single string

C. UrlBasedCorsConfigurationSource cannot be used here

D. The method should return void, not CorsConfigurationSource

Solution

1. Step 1: Check setAllowedOrigins parameter type

   The method setAllowedOrigins requires a List<String>, but the code passes a single String "*".

2. Step 2: Understand correct usage for wildcard

   To allow all origins, use List.of("*") instead of a plain string.

3. Final Answer:

   setAllowedOrigins expects a list, not a single string -> Option B

4. Quick Check:

   Allowed origins must be List<String> = B [OK]

Hint: setAllowedOrigins needs a list, not a string [OK]

Common Mistakes:

• Passing a string instead of a list to setAllowedOrigins
• Ignoring method parameter types
• Assuming missing HTTP methods cause errors here

5. You want to allow all origins but only GET and POST methods in your Spring Security CORS config. Which code snippet correctly achieves this while following best practices?

hard

A. configuration.setAllowedOriginPatterns(List.of("*")); configuration.setAllowedMethods(List.of("GET", "POST"));

B. configuration.setAllowedOrigins(List.of("*")); configuration.setAllowedMethods(List.of("GET", "POST"));

C. configuration.setAllowedOrigins("*"); configuration.setAllowedMethods(List.of("GET", "POST"));

D. configuration.setAllowedOrigins(List.of("*")); configuration.setAllowedMethods(List.of("GET", "POST", "PUT"));

Solution

1. Step 1: Understand wildcard origin allowance

   Using setAllowedOrigins(List.of("*")) is deprecated and may cause issues; instead, setAllowedOriginPatterns supports wildcards properly.

2. Step 2: Check allowed methods correctness

   Only GET and POST methods are allowed as required.

3. Final Answer:

   configuration.setAllowedOriginPatterns(List.of("*")); configuration.setAllowedMethods(List.of("GET", "POST")); -> Option A

4. Quick Check:

   Use allowedOriginPatterns for wildcard origins = A [OK]

Hint: Use setAllowedOriginPatterns for wildcard origins [OK]

Common Mistakes:

• Using setAllowedOrigins with "*" string
• Allowing extra HTTP methods by mistake
• Passing string instead of list to allowed origins