Cross Origin Resource Sharing (CORS) allows us to use Web applications within browsers when domains aren't the same

http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CORS_Filter  

This filter is an implementation of W3C's CORS (Cross-Origin Resource Sharing) specification, which is a mechanism that enables cross-origin requests.
The filter works by adding required Access-Control-* headers to HttpServletResponse object. The filter also protects against HTTP response splitting. If request is invalid, or is not permitted, then request is rejected with HTTP status code 403 (Forbidden). A flowchart that demonstrates request processing by this filter is available.
The minimal configuration required to use this filter is:

http://restlet.com/company/blog/2015/12/15/understanding-and-using-cors/ 

Cross Origin Resource Sharing (CORS) allows us to use Web applications within browsers when domains aren’t the same. For example, a site with domain test.org wants to execute AJAX requests to a Web application with domain mydomain.org using HTTP.

Using CORS isn’t so simple especially when you face debugging difficulties. As a matter of fact, CORS can imply an additional OPTIONS request and error messages aren’t so explicit. Most of the time, errors correspond to a lack of required headers from the server. For such reasons, a good understanding of how this feature works is essential.

CORS is used in a lot of places and use cases. In Web development, it’s often necessary to split the front application from the server application for development reasons or to interact with a remote service.

The CORS mechanism is mainly implemented with the Web server but this has an impact on the client side if some headers are missing in responses.