CORS — Cross-Origin Resource Sharing

1. Introduction

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that allows servers to specify which origins are permitted to read resources from their system, relaxing the browser's default Same-Origin Policy (SOP).

2. Why It Matters

By default, the Same-Origin Policy prevents client-side scripts on siteA.com from reading API responses from siteB.com. CORS provides a secure handshake protocol using HTTP headers, allowing servers to grant cross-origin read permissions to specific, trusted domains.

3. Real-World Analogy

Think of a Consular Passport Control Checkpoint:

• Same-Origin Policy (Sovereign border lock): A country locks its borders, allowing only its own citizens (scripts from the same origin) to trade goods.
• CORS Handshake (Visa checkpoint): A foreigner (cross-origin script) arrives at the gate. The border guard checks the consulate entry list: "Is this foreign origin allowed to trade?" (checks Access-Control-Allow-Origin). If the origin matches the whitelist, the foreigner enters. If they represent a blocklisted origin, they are turned away.
• Preflight OPTIONS (Courier verification): Before sending a cargo truck (a state-changing PUT/DELETE request), the foreign company sends a courier (an OPTIONS request) to ask the guard: "If we send a truck tomorrow carrying these items (headers), will you let it pass?" The guard approves or rejects the preflight request before the cargo truck is dispatched.

4. The CORS Handshake & Headers

When a cross-origin request is made, the browser automatically attaches the Origin header. The server must respond with the appropriate CORS headers to authorize access:
• Access-Control-Allow-Origin: Specifies which origins can read the response (e.g. https://trustedpartner.com or * for public APIs).
• Access-Control-Allow-Methods: Lists the HTTP methods allowed for cross-origin requests.
• Access-Control-Allow-Headers: Lists the custom HTTP headers allowed in requests.

5. Preflight (OPTIONS) Requests

For requests that could affect server state (such as POST requests with JSON payloads, or PUT/DELETE requests), the browser sends a preflight OPTIONS request first. This request checks if the server supports cross-origin requests before dispatching the actual request:

6. Practical Example

This Express backend configuration implements CORS security by restricting access to a specific, whitelisted domain:

7. Common Mistakes

• Setting Access-Control-Allow-Origin to "" when using credentials: If your API requests require cookies or authorization headers, you must set Access-Control-Allow-Credentials to true. When credentials are enabled, the wildcard origin * is blocked. You must return the explicit origin (read from the request's Origin header) instead.

// Express Endpoint
app.post('/api/save', (req, res) => {
  // Bug: setting Access-Control headers inside the route, but not handling OPTIONS preflight!
  res.setHeader('Access-Control-Allow-Origin', 'https://myclient.com');
  res.setHeader('Access-Control-Allow-Methods', 'POST');
  res.json({ saved: true });
});
// Client console output:
// Access to fetch at '/api/save' from origin 'https://myclient.com' has been blocked by CORS policy: 
// Response to preflight request doesn't pass access control check! Why?

// Enable CORS middleware globally for all routes and preflight checks
import cors from 'cors';
app.use(cors({ origin: 'https://myclient.com' }));

• • Never use Wildcard in Production: Avoid setting Access-Control-Allow-Origin: for private APIs in production. Always validate and restrict access to trusted origins to protect user data from unauthorized cross-origin requests.