In order to isolate potentially malicious scripts, same origin policy (SOP) prevents data coming from one origin to be read or executed by a script from another origin, and it also prevents some requests to be performed to another origin, when using specific HTTP methods or headers. For example, if you are browsing a site from one origin, your browser will not execute code contained in a response to a request to another origin. It also means that your scripts cannot perform a request to another origin, if those requests are not simple GET, HEAD, or POST requests with standard headers. By “origin” here, we mean a combination of protocol, host name, and port.
Strict SOP can be too restrictive for big web applications, which is why cross origin resource sharing (CORS) exists. CORS allows the server to relax the SOP restrictions and allow cross origin request and/or response reading and execution for specific caller origins and called endpoints. One important aspect to remember is that, although CORS rules are defined by the server, it is the browser’s responsibility to comply with them.
Spring provides easy ways to define your CORS policy. You can set them up centrally in a WebMvcConfigurer class, or through a @CrossOrigin annotation for a @Controller or @RequestMapping.
As a general advice, make sure you understand the way SOP and CORS work. They protect your users and your data only in conjunction with the browser. CORS can also have a very fine granularity—make sure you only allow the endpoints that need it, from the origins that need it.