CORS header reference
Access-Control-Allow-Origin: exact origins, wildcard, Vary, and credentials
Configure Access-Control-Allow-Origin safely for public APIs, credentialed requests, allowlists, CDN caches, and preflight responses.
Return one allowed origin or the wildcard—not a comma-separated list. Credentialed browser requests require an explicit origin. When the response varies by request Origin, include Vary: Origin so a shared cache does not serve one tenant’s CORS decision to another.
Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.
Diagnostic procedure
Work from evidence to recovery.
- 01
Validate the incoming origin
Compare the scheme, host, and port against a strict allowlist; do not reflect arbitrary origins.
- 02
Choose wildcard or credentials
Use * only for non-credentialed public access. Return the exact allowed origin for cookies or credential mode include.
- 03
Protect cache variants
Add Vary: Origin when responses can be cached and the allowed-origin value is selected dynamically.
Access-Control-Allow-Origin: https://a.example, https://b.example
Validate Origin → return one matching origin Vary: Origin
The modeled preflight policy admits this origin, method, header set, and credential mode.
No account · no upload · no endpoint calledOpen the full cors preflight lab and operating notes →
FAQ
Before you ship
Does APITC send this evidence to an API?
No. The matching and calculations in the linked workbench run in the active browser tab.
Should every CORS origin response be retried?
No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.
Protocol behavior checked against the MDN — Access-Control-Allow-Origin. Recheck your pinned provider/API version before production deployment.