I did some reading on CORS and I think I understand how they can restrict which origins the requests are coming from. However, allowing the cross origin calls from the browser increases a possibility of XSS:
a person with malicious intent injects some JavaScript into a page to steal users' cookies and send them to a URL he controls, all he has to do is add the following header
Access-Control-Allow-Origin: *on the server side to make the request work. https://security.stackexchange.com/questions/108835/how-does-cors-prevent-xss
The scenario that CORS is preventing is different:
For example, the victim logged into their bank's application. Then they were tricked into loading an external website on a new browser tab. The external website then used the victim's cookie credentials and relayed data to the bank application while pretending to be the victim. Unauthorized users then had unintended access to the bank application. To prevent such CSRF issues, all browsers now implement the same-origin policy. https://aws.amazon.com/what-is/cross-origin-resource-sharing/
the same-origin policy is highly secure but inflexible for genuine use cases. Cross-origin resource sharing (CORS) is an extension of the same-origin policy.
So by using CORS as an "extension" of older strict same-origin policy we now allow the XSS scenario to go through.
In fact, CORS weaken existing restrictions of SOP to help website developers to use shared data from other origins.
So if someone pulls a rogue JS library into their site from a different domain (which will of course allow any origin) that JS can steal user data and post them to any other domain (which will happily allow CORS from anywhere). That was not possible before with the strict same-origin policy in the browser.
The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring which dynamic resources are allowed to load. https://content-security-policy.com/