No. That's one potential risk, but hardly the only one.
The entire CORS dance is to work around the pre-existing browser based security model. It was specifically to create a backwards compatible model that would enable requests across origins, without compromising the existing security model.
This is a little overly simplified, but, consider how 'helpful' the browser is; when you make a request to a backend, any related cookie gets sent along with it. So, a danger realized early on was (by example), if someone was logged into their bank, and then accessed a malicious site, the malicious site could make a request to the bank to, say, transfer money. Because the bank used cookies for authentication, the transfer would be authorized and go through.
VPN is a similar risk, but even authenticated resources might be available, depending on the type of authentication (and, certainly, unauthenticated ones are exposed).
To prevent that, early on, they decided to block cross origin requests entirely. Well, almost; due to the nature of the web, GET requests had to be able to be made cross origin (it's why you can link to other websites/content), so they just prevented scripts from having access to the data. This was fine from a security standpoint, but it had a major usability issue. A lot of terrible workarounds were implemented (I'm looking at you, JSONP), with CORS being the official "this is how we'll allow you to, intentionally, relax this requirement, while still keeping the security decisions in place, and allow everything to be backwards compatible".
I thought origin policies could be applied at the cookie level such that the browser would only send the relevant cookies to your bank if the request originated from active user navigation to bank.com or from content served by the response received thereafter: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...? That way instead of service X saying "only requests from these origins are allowed", bank.com is saying "these cookies are sensitive please restrict them to requests that happen when the user has actually navigated to our website". In the bank scenario you presented, does CORS provide any additional benefit beyond cookie-level access control policies? Is there another scenario I'm missing in general?
SameSite was created by Google in 2016, and required both adoption across browsers and backend changes to be secure (that is, reliance on SameSite being set for security would mean backends that don't set it are not secure; it is opt in).
Preventing cross origin requests as a necessary security measure happened as part of the initial implementation of XmlHttpRequest back in the 90s.
CORS was a working draft as early as 2006, implemented across browsers by 2013ish, accepted as a W3C recommendation in 2014, and was 'secure by default'; the only backend changes necessary were when you wanted to allow cross origin requests (that is, it is opt out).
The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option.
In practice, most sites want to prevent all cross-origin requests and SameSite is easier.
And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.
We just ran into this CORS Same-Site cookie issue and it is going to become much more common. If the original author expanded to include the Same-Site rules as it applies to cookies it would be great!
The entire CORS dance is to work around the pre-existing browser based security model. It was specifically to create a backwards compatible model that would enable requests across origins, without compromising the existing security model.
This is a little overly simplified, but, consider how 'helpful' the browser is; when you make a request to a backend, any related cookie gets sent along with it. So, a danger realized early on was (by example), if someone was logged into their bank, and then accessed a malicious site, the malicious site could make a request to the bank to, say, transfer money. Because the bank used cookies for authentication, the transfer would be authorized and go through.
VPN is a similar risk, but even authenticated resources might be available, depending on the type of authentication (and, certainly, unauthenticated ones are exposed).
To prevent that, early on, they decided to block cross origin requests entirely. Well, almost; due to the nature of the web, GET requests had to be able to be made cross origin (it's why you can link to other websites/content), so they just prevented scripts from having access to the data. This was fine from a security standpoint, but it had a major usability issue. A lot of terrible workarounds were implemented (I'm looking at you, JSONP), with CORS being the official "this is how we'll allow you to, intentionally, relax this requirement, while still keeping the security decisions in place, and allow everything to be backwards compatible".