About CORS Explained

Same-origin rule, simple vs preflight, server headers, gotchas. Part of the DevTools Surf developer suite. Browse more tools in the Info / Guides collection.

Use Cases

• Frontend devs debugging 'No Access-Control-Allow-Origin' browser errors
• Backend developers configuring CORS headers for API endpoints
• Full-stack teams setting up local dev proxies to avoid CORS issues
• Security engineers auditing overly permissive wildcard CORS policies

Tips

• Read the simple vs preflight request distinction to debug 403 errors
• Check the server header examples for your specific backend framework
• Use the gotchas section to fix credentialed request cookie issues

Fun Facts

• The same-origin policy was introduced by Netscape Navigator 2.0 in 1995 to prevent malicious scripts from reading data from other domains.
• CORS (Cross-Origin Resource Sharing) was standardized as a W3C Recommendation in January 2014 after years of workarounds like JSONP.
• A CORS preflight is an OPTIONS request the browser sends automatically — it was designed to protect legacy servers that never expected cross-origin requests.

FAQ

What is the same-origin policy?

Browsers block scripts from reading data across different origins (protocol+host+port). CORS is how a server explicitly opts into cross-origin access.

Simple vs preflight?

Simple requests (GET/POST with specific headers) go direct. Preflight (OPTIONS) is sent first for anything with custom headers, PUT/DELETE, etc.

What headers matter?

Server side: Access-Control-Allow-Origin, -Methods, -Headers, -Credentials. Client side: withCredentials flag controls cookie inclusion.

Why does CORS fail mysteriously?

Common: the server allows origin * but also sets Access-Control-Allow-Credentials: true (forbidden combo). Or the preflight OPTIONS request is blocked by middleware.