In more detail
Browsers apply the same-origin policy: a script on one site may not read data from another origin (scheme, host and port) unless that origin opts in with headers such as Access-Control-Allow-Origin. Simple requests, such as a plain GET, are sent directly and the browser checks the response headers. For other requests (a PUT, a JSON body, custom headers) the browser first sends an OPTIONS preflight to ask permission. The wildcard * allows any origin but cannot be combined with cookies or other credentials.
Why it matters
A "CORS error" in the console means the server did not opt in; the fix belongs on the server, not in front-end code. Reflecting any Origin back together with Access-Control-Allow-Credentials: true lets every website read your logged-in users' data. CORS protects users in the browser; it does not stop other programs calling the API.
Example
OPTIONS /api/orders HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, PUT
Common confusion
A Content Security Policy (CSP) limits what your own page may load; CORS decides which other origins may read your server's responses.