If you have ever seen the error "Access to fetch has been blocked by CORS policy" in your browser console, you are not alone. CORS is one of the most frequently encountered — and misunderstood — concepts in web development. This guide explains what CORS is, why it exists, and how to configure it properly so your APIs and frontends work together seamlessly.
What Is CORS and Why Does It Exist
Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which domains can make requests to your server. By default, browsers enforce the Same-Origin Policy, which prevents a webpage at one domain from making requests to a different domain. This protects users from malicious sites that might try to steal data from APIs they are authenticated with.
CORS relaxes this restriction in a controlled way. When your frontend at app.example.com needs to call an API at api.example.com, the browser sends a CORS request and checks whether the server explicitly permits that origin. If it does, the request proceeds. If not, the browser blocks it — even though the server may have already processed and responded to the request.
How CORS Works
CORS operates through HTTP headers. The key headers involved are:
- Access-Control-Allow-Origin: Specifies which origins are permitted. This can be a specific domain or a wildcard (*), though wildcards cannot be used with credentialled requests.
- Access-Control-Allow-Methods: Lists the HTTP methods (GET, POST, PUT, DELETE) the server accepts from cross-origin requests.
- Access-Control-Allow-Headers: Specifies which custom headers the client is allowed to send, such as Authorization or Content-Type.
- Access-Control-Max-Age: Tells the browser how long to cache the preflight response, reducing the number of OPTIONS requests sent.
Preflight Requests
For requests that are not "simple" — those using methods other than GET, HEAD, or POST, or including custom headers — the browser sends a preflight OPTIONS request before the actual request. This preflight asks the server whether the real request will be allowed. Only if the server responds with the appropriate CORS headers does the browser proceed with the actual request.
Preflight requests can add latency to your API calls if not handled efficiently. Setting a generous Access-Control-Max-Age header (such as 86400 seconds for 24 hours) allows browsers to cache the preflight response and skip subsequent OPTIONS requests for the same endpoint.
Common Mistakes and Fixes
The most frequent CORS mistake is setting Access-Control-Allow-Origin: * while also trying to send cookies or authentication headers. The browser will reject this combination. If you need credentials, you must specify the exact origin and set Access-Control-Allow-Credentials: true.
Another common issue is forgetting to handle the OPTIONS preflight method in your server routing. Many frameworks require explicit route handlers for OPTIONS, or a middleware that intercepts preflight requests before they reach your application logic. In Express.js, the cors npm package handles this automatically. In Laravel, the built-in CORS middleware covers it.
CORS in Production
In production, always whitelist specific origins rather than using wildcards. Maintain an environment-based list of allowed origins and validate incoming requests against it. This approach is more secure and allows you to support multiple frontends (staging, production, preview deployments) without opening your API to the entire internet.
At Born Digital, we configure CORS as part of our standard API setup process. Getting it right from the start avoids frustrating debugging sessions later and ensures your frontend and backend communicate securely across origins. If you are struggling with CORS errors in your project, the fix is almost always a server-side configuration change — not a frontend workaround.