In case of an open API, the only possible value for Access-Control-Allow-Origin is a wildcard (*), since you can't have a list of allowed domains.
Having a static
* is one way. Other ways are to dynamically return the currently requesting origin inside the
Access-Control-Allow-Origin header. These options slightly differ in semantics, specifically regarding handling credentials like cookies.
Still, this seems not to bug developpers and appears to keep the system secure.
Since there are no actual security requirements for the API (i.e. everybody should be able to use it, even cross-origin) CORS does not keep the system secure. What the wildcard
Access-Control-Allow-Origin instead does is to make the system working cross-origin in the first place: without any CORS header in the HTTP response any XHR interaction (i.e. write request and read response) could only be done to the same origin because of the default SOP for XHR.
... but as I understood it, it avoid an unwanted domain to use session cookies of a user without his consent.
CORS does not forbid things that are possible without CORS. It is still possible to send simple requests cross-origin with credentials (cookies ...) included, both with XHR and by including images cross-origin, sending forms cross-origin etc.
But CORS makes it possible to not only send simple requests but also non-simple requests (with additional headers, different content-types etc) and to read the responses for simple and non-simple requests. And when credentials are used not only
Access-Control-Allow-Origin is relevant but also
Access-Control-Allow-Origin: if this is not explicitly set to true the response will not be available to the script in the browser, similar to how it was done without CORS.