A control enforced by the browser, not the server
Cross-origin resource sharing controls whether a script running on one website can read a response from a different website's server, and it's enforced by the browser examining the server's response headers, not by the server itself deciding whether to grant the request. This distinction matters more than it initially seems to: the protection only applies to the specific scenario of a browser mediating between two origins.
A request made outside that scenario — directly from a server, a script, or any client that isn't a browser enforcing CORS — is entirely unaffected by however permissive or restrictive the CORS configuration is. The header does nothing to stop it, because the check it configures never applies to that kind of caller in the first place.
Why this gets confused with authorization
A permissive CORS setup often gets flagged during a security review as if it were equivalent to leaving a resource unauthenticated, because the symptom — a browser can now read data it couldn't before — looks like an access-control failure. But the actual gate the resource needs is server-side authorization applied regardless of caller; CORS configuration is a separate, narrower control layered on top of that, not a substitute for it. A resource with correct server-side authorization and permissive CORS is still protected from unauthorized access — just not from a legitimate, authorized browser session reading its own authorized data across origins, which is what CORS actually governs.