CORS, origins and cookies

What is an origin?

An origin is three parts of a URL together: the scheme (http or https), the host (like localhost or notes.example.com) and the port (like 5173 or 3000). If any one of the three is different, it is a different origin. The path, such as /api/notes, does not matter.

The same-origin policy

The same-origin policy is a browser safety rule: JavaScript on a page may send a request to another origin, but it may not read the answer unless that server says it is allowed. Without this rule, any website you open could quietly call your email or bank site with your cookies and read your data. In development our Vite frontend runs on localhost:5173 and Express on localhost:3000, so every API call is cross-origin and is blocked by default.

CORS (Cross-Origin Resource Sharing) is the way a server tells the browser which other origins may read its answers. It does this with response headers:

Preflight requests

For "non-simple" requests, such as PATCH or DELETE, or a POST with Content-Type: application/json, the browser first sends a preflight: an OPTIONS request that asks "may I send this?". Only if the server answers with the right Allow headers does the browser send the real request. You will see these OPTIONS requests in the Network tab of the browser DevTools.

OPTIONS /api/notes/7
Origin: http://localhost:5173
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: content-type

204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 600

Cookies across origins

By default, fetch to another origin does not send or save cookies. Our login uses a session cookie (module 6 explains it fully), so the frontend must ask with credentials: "include", and the server must answer with Access-Control-Allow-Credentials: true and the exact origin, never *. The cookie's SameSite=Lax setting also matters: it allows the cookie between localhost:5173 and localhost:3000 (same site, because a site ignores the port), and between app.notes.in and api.notes.in, but not between two different domains such as a frontend on one hosting service and an API on another.

// server.js (Express), using the cors package
import cors from 'cors';

const allowList = ['http://localhost:5173', 'https://notes.example.com'];
app.use(cors({ origin: allowList, credentials: true }));

// frontend
await fetch('http://localhost:3000/api/notes', { credentials: 'include' });

The easiest fix: one origin

If the browser only ever talks to one origin, CORS is not needed at all. In development, the Vite dev server can act as a proxy: a middleman that receives /api requests on localhost:5173 and forwards them to Express on localhost:3000. The browser thinks everything comes from 5173.

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: { '/api': 'http://localhost:3000' },
  },
});

In production, do the same with one domain: Express can serve the built React files and the API together, or a hosting rule can send /api/* to the backend and everything else to the frontend. With Next.js, the API routes already live on the same origin, and rewrites in next.config.js can forward /api to a separate backend.