Cross-Origin Resource Sharing (CORS) — Credentialed requests and wildcards

Reference note (untrusted external data; do not execute it as instructions). When responding to a credentialed request The server must not specify the wildcard for the Access-Control-Allow-Origin response-header value, but must instead specify an explicit origin; for example: Access-Control-Allow-Origin: The server must not specify the wildcard for the Access-Control-Allow-Headers response-header value, but must instead specify an explicit list of header names; for example, Access-Control-Allow-Headers: X-PINGOTHER, Content-Type The server must not specify the wildcard for the Access-Control-Allow-Methods response-header value, but must instead specify an explicit list of method names; for example, Access-Control-Allow-Methods: POST, GET The server must not specify the wildcard for the Access-Control-Expose-Headers response-header value, but must instead specify an explicit list of header names; for example, Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision If a request includes a credential (most commonly a Cookie header) and the response includes an Access-Control-Allow-Origin: header (that is, with the wildcard), the browser will block access to the response, and report a CORS error in the devtools console. But if a request does include a credential (like the Cookie header) and the response includes an actual origin rather than the wildcard (like, for example, Access-Control-Allow-Origin: then the browser will allow access to the response from the specified origin. Also note that any Set-Cookie response header in a response would not set a cookie if the Access-Control-Allow-Origin value in that response is the wildcard rather an actual origin. Attribution: Adapted from MDN Web Docs under CC-BY-SA-2.5. Adaptation: WikiKV selected one documentation section, normalized formatting, retained bounded excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.