BACKEND

Home › Glossary › Backend· 106 ·

CORS

\\kors\\n.

Filed underBackendSecurityApisFront EndSoftware Engineering

In brief · quick answer

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which web pages can request resources from a different origin. It uses HTTP headers to define allowed origins, methods, and headers for cross-origin requests.

§ 1 Definition

CORS is a browser security feature that prevents one web page from making requests to a different origin than the one that served the page, unless that origin explicitly permits it. An origin is defined by the scheme (http/https), host (domain), and port. Two URLs are different origins if any of these differ. CORS is not a backend security mechanism. It is enforced by the browser, not the server. The server sets CORS headers, and the browser enforces them. The CORS protocol has two request types. Simple requests (GET, HEAD, POST with standard content types and no custom headers) are sent directly with the Origin header. The browser checks the response's Access-Control-Allow-Origin header. Preflighted requests (PUT, DELETE, PATCH, requests with custom headers or non-standard content types) first send an OPTIONS preflight request to check permissions before sending the actual request. CORS errors happen on the browser side. The server receives the request and processes it. The browser blocks the response if CORS headers are missing or incorrect. This is why CORS errors show 200 status codes in the network tab but the response is not available to JavaScript.

§ 2 How CORS Works

CORS is a negotiation between the browser and server through HTTP headers. The browser includes an Origin header in every cross-origin request. The server responds with Access-Control-Allow-Origin specifying which origins are allowed. A value of * allows all origins (public API). A specific origin (https://myapp.com) allows only that origin. For credentialed requests (cookies, authorization headers), the server must specify an exact origin, not *. Additional headers control allowed methods (Access-Control-Allow-Methods), allowed headers (Access-Control-Allow-Headers), whether credentials are allowed (Access-Control-Allow-Credentials), cache duration for preflight responses (Access-Control-Max-Age), and which response headers the browser can expose to JavaScript (Access-Control-Expose-Headers).

§ 3 Preflight Requests

When a request uses HTTP methods other than GET/HEAD/POST, or adds custom headers, or uses a non-standard content type (not application/x-www-form-urlencoded, multipart/form-data, or text/plain), the browser sends a preflight request. This is an OPTIONS request with the Origin, Access-Control-Request-Method, and Access-Control-Request-Headers headers. The server must respond with the appropriate CORS headers. If the preflight is successful, the browser sends the actual request. If the preflight fails, the browser blocks the actual request entirely. Preflight requests add latency (one extra round trip) and can cause confusion in development when the server handles the main request but does not handle OPTIONS. Your API server must handle OPTIONS requests and return correct CORS headers for the actual request to proceed.

§ 4 Common CORS Pitfalls

The most common CORS mistake is using Access-Control-Allow-Origin: * with credentials. The browser requires an exact origin when Access-Control-Allow-Credentials: true is set. Another common issue: the preflight response is cached by the browser (Access-Control-Max-Age), so after changing CORS configuration, users may see stale behavior until the cache expires. CORS and proxies: if you run a reverse proxy or API gateway, CORS headers must be set at the edge (the proxy), not the backend service, because the browser talks to the proxy. In development, use a proxy in your front-end dev server (Vite's proxy option, Create React App's proxy) to avoid CORS entirely. In production, configure CORS properly on your API server. Also: CORS only applies to browser-based requests. Server-to-server, curl, Postman, and mobile apps are not affected by CORS.

§ 5 Note

Common misunderstanding: CORS is not a security vulnerability. It is a security feature. It prevents malicious websites from reading data from your API using the authenticated user's browser session. CORS does not protect your API from direct requests (curl, Postman, mobile apps). API security requires authentication (JWT, API keys), not CORS. Another misconception: CORS errors mean the server rejected the request. The server receives and processes the request. The browser blocks the response from being read by JavaScript. You might see a 200 status with a CORS error in the browser console. Also: CORS configuration is not a substitute for proper authentication and authorization on your API.

§ 6 In code

```javascript
// Express.js CORS middleware
import cors from 'cors';
import express from 'express';

const app = express();

const corsOptions = {
  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:5173',
  methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400, // Cache preflight for 24 hours
};

app.use(cors(corsOptions));

// Handle preflight explicitly if needed (cors() does this automatically)
app.options('*', cors(corsOptions));

app.get('/api/data', (req, res) => {
  res.json({ message: 'CORS configured correctly!' });
});
```

§ 7 Common questions

Q. Why am I getting a CORS error in development?: A. Your front-end (localhost:5173) and back-end (localhost:3000) have different origins. Use the Vite/Webpack proxy configuration during development to avoid CORS. For production, configure CORS headers on your API server.
Q. Can CORS be bypassed?: A. CORS is enforced by the browser. Server-to-server calls, mobile apps, and tools like Postman do not enforce CORS. CORS is a browser security mechanism, not an API security mechanism.
Q. Should I use CORS wildcard (*) in production?: A. Only for public APIs that serve data to all origins and do not use cookies or authentication headers. For authenticated APIs, always specify exact origins.

Key takeaways

CORS is a browser-enforced security mechanism that controls cross-origin resource access via HTTP headers.
Preflight requests (OPTIONS) are sent for non-simple requests before the actual request.
CORS protects browsers, not APIs. API security requires authentication and authorization.
Use exact origins (not *) for authenticated APIs. Handle OPTIONS preflight requests on your server.

How Atomic Glue helps

Atomic Glue configures CORS correctly on every API we build. We set specific allowed origins (never wildcards for authenticated APIs), handle preflight OPTIONS requests, and configure the proxy in development to avoid CORS issues entirely. CORS configuration is part of the security hardening we apply in our Web Development services. Get in touch to secure and configure your API.

Get in touch

# CORS

Category: Backend (also: Security, Apis, Front End, Software Engineering)

Author: Atomic Glue Development Team

## Definition

## How CORS Works

## Preflight Requests

## Common CORS Pitfalls

## Note

## In code

## Common questions
Q: Why am I getting a CORS error in development?
A: Your front-end (localhost:5173) and back-end (localhost:3000) have different origins. Use the Vite/Webpack proxy configuration during development to avoid CORS. For production, configure CORS headers on your API server.
Q: Can CORS be bypassed?
A: CORS is enforced by the browser. Server-to-server calls, mobile apps, and tools like Postman do not enforce CORS. CORS is a browser security mechanism, not an API security mechanism.
Q: Should I use CORS wildcard (*) in production?
A: Only for public APIs that serve data to all origins and do not use cookies or authentication headers. For authenticated APIs, always specify exact origins.

## Key takeaways

CORS is a browser-enforced security mechanism that controls cross-origin resource access via HTTP headers.
Preflight requests (OPTIONS) are sent for non-simple requests before the actual request.
CORS protects browsers, not APIs. API security requires authentication and authorization.
Use exact origins (not *) for authenticated APIs. Handle OPTIONS preflight requests on your server.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/cors-backend