Some of you folks might remember an OSS wiki application called MindTouch (during the mid to late aughts) that later pivoted into a SaaS company. This is the same hosted software running the LibreTexts libraries, as the company and all assets were acquired by NICE. The LibreTexts team out of UC Davis built significant customizations on top of the existing base platform, which includes many custom user interface components. That being said, as the years went by, the software was repositioned and sold as a knowledge base for customer support teams and call centers, so this library-like information architecture is more or less layered on top of software that is specialized for a different use case.
Disclaimer: I was formerly a lead engineer and director for MindTouch, Inc.
The company I work for provides embeddable JavaScript "web widgets". Our customers are companies, and their customers are consumers (we are business to business to consumer company). We host somewhat personal data specific to those consumers, and as such, the data should only be accessible by those consumers.
So, we provide the data API that these web widgets communicate with, and the web widgets themselves can be embedded on our customers' own websites (some-company.com). However, the customer can decide exactly which hostnames can embed the widget (through a control panel we provide), and these hostnames ultimately become the `Access-Control-Allow-Origin` value we provide with every API response. Perhaps they want it on foo.some-company.com or bar.some-company.com -- it's really up to our customer where they want these widgets to be embedded.
By doing this, the customer knows that no other website can host these widgets, thus exposing their consumers' data to a phishing attack as I outline here: https://news.ycombinator.com/item?id=20405169
Access to an API should be managed by a proper authentication or token validation scheme. However, protecting your users' authenticated API sessions, which are presumably initialized by the forementioned authentication scheme, is what CORS enables.
CORS, when implemented correctly, ensures that a session is not hijacked by a malicious website's JavaScript in order to call your API in the context of the session (effectively masquerading as the user who authenticated with your API). This scenario assumes that there is an authentication session cookie, tied to your API domain, that the browser would pass along with any request to your API domain (of course there are SameSite cookie and third party cookie blockers that can mitigate these situations as well, but perhaps "trusted" cross domain requests are desired in this use case)
With CORS allowing traffic from anywhere on the web, you can't reliably trust that the authenticated sessions to your API are not being used in phishing / side channel attacks: I discover your are authenticated on site on foo.example.com and I send you a link to my website, evil.com. Evil.com includes JavaScript to request data from an API on foo.example.com. Your browser executes the JavaScript and makes the request and gets a response payload, and since I'm a jerk I then post that same payload to my own endpoint on evil.com to capture the data.
Of course this all assumes that you WANT your API to be accessible cross origin. If you provide an API as a product this is common, since it allows other developers to build web apps against your API. If that is not a use case, then same origin policy (and no CORS headers from the API server) is sufficient to prevent malicious domains from doing bad stuff with your users' authenticated sessions.
Some of you folks might remember an OSS wiki application called MindTouch (during the mid to late aughts) that later pivoted into a SaaS company. This is the same hosted software running the LibreTexts libraries, as the company and all assets were acquired by NICE. The LibreTexts team out of UC Davis built significant customizations on top of the existing base platform, which includes many custom user interface components. That being said, as the years went by, the software was repositioned and sold as a knowledge base for customer support teams and call centers, so this library-like information architecture is more or less layered on top of software that is specialized for a different use case.
Disclaimer: I was formerly a lead engineer and director for MindTouch, Inc.