CORS Explained and How to Fix It

What is CORS Anyway?

Ever hit a wall with your web application, staring at a cryptic browser error like “Access to fetch at ’…’ from origin ’…’ has been blocked by CORS policy”? Yeah, me too. It’s a common frustration, but understanding it is key to building robust web apps. CORS, or Cross-Origin Resource Sharing, is a security feature implemented by web browsers. It prevents a web page from making requests to a different domain than the one that served the web page. Think of it like your bank’s security system. You can access your account from your computer at home (same origin), but your neighbor can’t just walk up to your computer and access your bank from their own browser session (different origin).

The Same-Origin Policy (SOP)

CORS is built upon the Same-Origin Policy (SOP). SOP dictates that a web page can only make requests to resources that originate from the exact same protocol, domain, and port. If any of these differ, it’s considered a “cross-origin” request. Modern web applications often need to fetch data from different domains – maybe your frontend is on app.example.com and your API is on api.example.com, or even worse, on a completely different service like some-third-party-api.com. This is where CORS comes in.

How CORS Works: The Preflight Request

When your JavaScript code tries to make a cross-origin request (e.g., using fetch or XMLHttpRequest), the browser steps in. For certain types of requests, the browser first sends an “OPTIONS” HTTP request to the server. This is called a “preflight request.” The purpose of this preflight request is to ask the server for permission before the actual request is sent. The server responds to the OPTIONS request with specific headers that tell the browser whether the actual request is allowed.

Key headers involved in a preflight request include:

• Access-Control-Allow-Origin: This is the most crucial header. It specifies which origins are allowed to access the resource. A wildcard * means any origin is allowed (use with caution!).
• Access-Control-Allow-Methods: Lists the HTTP methods (e.g., GET, POST, PUT, DELETE) that are allowed for the requested resource.
• Access-Control-Allow-Headers: Specifies the custom HTTP headers that the client is allowed to send in the actual request.

If the preflight request is successful (i.e., the server says “yes” via these headers), the browser then proceeds to send the original, actual request (e.g., a GET or POST).

Common CORS Errors and How to Fix Them

Most CORS errors stem from the server not sending the correct Access-Control-* headers, or sending headers that don’t match the browser’s expectations.

1. Missing Access-Control-Allow-Origin Header:

This is the most frequent culprit. The server needs to explicitly allow requests from your frontend’s origin.

• Problem: Your frontend (e.g., http://localhost:3000) tries to fetch data from your API (http://localhost:5000). The API server doesn’t return an Access-Control-Allow-Origin header.

• Solution: Configure your API server to include the correct header. For example, in Node.js with Express:

  1
  const express = require('express');
  2
  const app = express();
  3
  
  4
  app.use((req, res, next) => {
  5
    res.setHeader('Access-Control-Allow-Origin', 'http://localhost:3000'); // Or '*'
  6
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  7
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  8
    next();
  9
  });
  10
  
  11
  // Your API routes here...
  12
  
  13
  app.listen(5000, () => console.log('API server running on port 5000'));

  Important: For production, avoid using * for Access-Control-Allow-Origin unless absolutely necessary. It’s better to specify the exact origin of your frontend.

2. Request Method Not Allowed:

Your frontend is trying to use a method (like PUT or DELETE) that the server hasn’t allowed in its CORS headers.

• Solution: Ensure Access-Control-Allow-Methods in the server’s response includes the methods your frontend is using.

3. Custom Headers Not Allowed:

If you’re sending custom headers (like X-My-Custom-Header or Authorization), the server needs to explicitly permit them.

• Solution: Add your custom headers to the Access-Control-Allow-Headers response from the server.

4. Proxying Requests (Development):

In development, it’s common to run your frontend and backend on different ports locally. Instead of configuring CORS on your backend for every local port you might use, you can use a proxy.

• Solution (React Example): In your package.json:

  1
  {
  2
    "name": "my-app",
  3
    "version": "0.1.0",
  4
    "proxy": "http://localhost:5000"
  5
  }

  This tells Create React App to proxy any requests it doesn’t recognize to http://localhost:5000. The browser sees requests to localhost:3000 as originating from localhost:3000, and the API requests are effectively handled by the same origin server (or proxied, so the browser doesn’t see a cross-origin issue). This is a development-only solution.

Production Considerations

For production, always configure your backend server to send the correct CORS headers. Specify your frontend’s exact origin in Access-Control-Allow-Origin. If you have a complex setup with CDNs or multiple subdomains, ensure your server is configured to handle all valid origins that need to access your API.

Understanding CORS isn’t just about fixing errors; it’s about understanding how browsers protect users and how servers communicate their capabilities. Get this right, and you’ll save yourself a lot of debugging headaches.