Chapter 10: Configuring CORS
Introduces why browsers restrict cross-origin requests and why web applications may need CORS to permit them.
After this chapter you will be able to
- Browser Restrictions and CORS. Explain that browsers normally prevent a website from making requests to a different origin, and that CORS can relax this restriction under certain conditions. Describe why this matters when a frontend and backend are hosted at different domains.
- Cross-origin permissions and headers. Explain why a browser needs CORS information for calls between different origins and describe what the three named CORS response headers control.
- Browser rejection versus endpoint access. Describe what happens in the section's localhost-to-127.0.0.1 example when no CORS policy is configured, and distinguish the browser's rejection of a response from preventing an endpoint call.
- Endpoint-level CORS configuration. Describe how to place @CrossOrigin above a controller endpoint method and configure its allowed origins, headers, and methods. Explain that adding it above test() allows the example’s localhost cross-origin call.
- Wildcard permission risks. Explain what an asterisk permits for origins or headers and why the section recommends explicitly filtering them instead, especially origins.
- Centralized CORS configuration path. Describe how the example moves CORS configuration from @CrossOrigin annotations into the security configuration class using a Customizer<CorsConfigurer> and a CorsConfigurationSource.
- Required origins and methods. Explain what a CorsConfiguration can specify and why this approach requires explicitly configuring both allowed origins and methods.
Section by section
Introduction
Introduces why browsers restrict cross-origin requests and why web applications may need CORS to permit them.
- Browser Restrictions and CORS: Explain that browsers normally prevent a website from making requests to a different origin, and that CORS can relax this restriction under certain conditions. Describe why this matters when a frontend and backend are hosted at different domains.
Why it matters: This explains why a frontend may be unable to call its backend even when both applications are working.
Key terms: cross-origin resource sharing (CORS), origins, frontend, backend
10.1 How does CORS work?
This section explains how browsers handle cross-origin requests, how CORS response headers affect access to responses, and why CORS does not secure an endpoint.
- Cross-origin permissions and headers: Explain why a browser needs CORS information for calls between different origins and describe what the three named CORS response headers control.
Why it matters: These headers express which cross-origin browser interactions your application permits. - Browser rejection versus endpoint access: Describe what happens in the section's localhost-to-127.0.0.1 example when no CORS policy is configured, and distinguish the browser's rejection of a response from preventing an endpoint call.
Why it matters: A CORS error does not prove that the backend endpoint was never reached. - Browser preflight request behavior: Distinguish a cross-origin request sent directly from one preceded by a browser preflight request, including what happens when the preflight fails.
Why it matters: Preflight explains why some cross-origin calls reach an endpoint while others stop before the original request.
Key terms: CORS, origin, Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, localhost, 127.0.0.1, browser, endpoint, preflight request
10.2 Applying CORS policies with the @CrossOrigin annotation
This section shows how to apply CORS rules to individual endpoints with @CrossOrigin and explains the benefits and risks of that approach.
- Endpoint-level CORS configuration: Describe how to place @CrossOrigin above a controller endpoint method and configure its allowed origins, headers, and methods. Explain that adding it above test() allows the example’s localhost cross-origin call.
Why it matters: You can allow a needed cross-origin call while keeping the rule attached to the endpoint it affects. - Wildcard permission risks: Explain what an asterisk permits for origins or headers and why the section recommends explicitly filtering them instead, especially origins.
Why it matters: A permissive CORS rule can expose resources to requests the application did not intend to allow. - Per-endpoint annotation tradeoffs: Distinguish the transparency of defining CORS rules at endpoints from the repetition and omission risk this creates.
Why it matters: This tradeoff helps you recognize when endpoint-by-endpoint rules may become hard to maintain.
Key terms: @CrossOrigin, value, allowedHeaders, methods, allowed origin, asterisk (*), origins, headers, cross-site scripting (XSS), DDoS attacks
10.3 Applying CORS using a CorsConfigurer
This section shows how to centralize CORS configuration through HttpSecurity and explains why both allowed origins and methods must be specified.
- Centralized CORS configuration path: Describe how the example moves CORS configuration from @CrossOrigin annotations into the security configuration class using a Customizer<CorsConfigurer> and a CorsConfigurationSource.
Why it matters: This gives you one place to define CORS policy instead of relying on annotations at individual endpoints. - Required origins and methods: Explain what a CorsConfiguration can specify and why this approach requires explicitly configuring both allowed origins and methods.
Why it matters: An origins-only configuration looks plausible but will not allow the intended requests.
Key terms: @CrossOrigin, HttpSecurity, cors(), Customizer<CorsConfigurer>, CorsConfigurationSource, CorsConfiguration, allowed origins, methods, headers
10.4 Summary
Where this is used later
- Testing CORS configurations (chapter 18) · How CORS uses response headers to govern cross-origin responses
Concepts explained in this chapter
- CORSCross-origin resource sharing is a browser security mechanism that controls whether a web page may access resources from another origin.
- Access-Control-Allow headersAccess-Control-Allow-Origin is an HTTP response header that specifies which origins may access a resource through cross-origin requests.
- HTTP headerAn HTTP header is a field in an HTTP request or response that conveys metadata or control information.
- access-control-allow-methodsAccess-Control-Allow-Methods is an HTTP response header that specifies the HTTP methods permitted for cross-origin requests.
- browserA web browser is client software that retrieves, renders, and executes web resources on behalf of a user.
- originAn origin is the scheme, host, and port tuple that identifies the security context of a web resource.
- preflight requestA preflight request is a browser-generated HTTP request that tests whether a cross-origin request is permitted before the browser sends the original request.
← Chapter 9: Configuring CSRF protection
Chapter 11: Implementing authorization at the method level →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.