Cross-Origin Resource Sharing (CORS) uses HTTP headers to instruct a browser if a request is allowed to be made. The browser performs the request and checks if there are any CORS related headers. If the headers are present and the current hostname is “whitelabeled” in the server’s CORS policy, the browser will allow the request.
For example, if website a.com implements a CORS policy that only requests from a.com can fetch resources, then if website b.xyz attempts to programatically load images from a.com the server will instruct the browser to not allow these requests. However, the owner of b.xyz can create a simple proxy server that strips any related CORS headers. Then b.xyz makes a request to cors-stripper.com/a.com/cute_pupper.png and can ignore any CORS policies implement by a.com.
A browser will follow the same origin policy by default where requests made to
a different domain will fail. This can be turned off via setting the mode of a
'no-cors' but this will severely restrict the request to prevent
sending anything sensitive.
'no-cors' will restrict the request to
- only allow GET, POST requests with simple headers 
- unable to read the response if the request was made via a POST
So in order to perform a request without just simple headers (like the
Authorization header) the mode must be set to
'cors' and the server must return
the correct CORS related headers. This prevents malicious sites from submitting
cookies on behalf of a user to another site.
-  As this request is performed by the browser, the attacker will have to make another request to a server she owns with the token.
-  Simple Headers