cors (Express CORS middleware)
Express.js middleware for configuring Cross-Origin Resource Sharing (CORS) headers. Handles the browser's same-origin policy by setting Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and related CORS headers on HTTP responses. Supports whitelist-based origin validation, preflight OPTIONS request handling, credential cookies, and dynamic per-request origin configuration. Part of the expressjs GitHub organization.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
CORS is browser-enforced security — not a server-side security boundary. Properly configured CORS restricts browser cross-origin access. Credentials: true requires explicit origin, not wildcard. Not a substitute for server-side auth.
⚡ Reliability
Best When
You're building an Express.js API that needs to accept browser requests from different origins (different domains, ports, or protocols).
Avoid When
You're using a different framework (Fastify, Hono, Koa) — use their native CORS plugins. CORS is only relevant for browser-to-server communication.
Use Cases
- • Enable CORS for an Express.js API to allow browser requests from a different domain (e.g., React frontend at localhost:3000 calling API at localhost:8000)
- • Restrict API access to specific allowed origins using whitelist-based origin validation for production APIs
- • Handle CORS preflight OPTIONS requests automatically so complex requests (PUT, DELETE with custom headers) work from browsers
- • Allow credentials (cookies, Authorization headers) in cross-origin requests using credentials: true option
- • Configure per-route CORS policies — public endpoints allow *, authenticated endpoints restrict to known origins
Not For
- • Non-Express frameworks — for Fastify use @fastify/cors; for Koa use @koa/cors; for Hono use Hono's built-in cors middleware
- • Complete security solution — CORS is browser-enforced only; server-side auth is still required; CORS doesn't prevent server-to-server abuse
- • Complex dynamic CORS rules — for complex per-request logic, implement custom middleware instead
Interface
Authentication
No authentication — HTTP header middleware. CORS itself is not an auth mechanism — it restricts browser access but server must still implement auth.
Pricing
Fully free, MIT licensed.
Agent Metadata
Known Gotchas
- ⚠ origin: '*' (allow all) is incompatible with credentials: true — browsers reject CORS with wildcard origin AND credentials; must specify explicit origins when using credentials
- ⚠ CORS errors appear in browser console, not server logs — when debugging CORS issues, always check browser Network/Console tabs for the actual CORS error message
- ⚠ Preflight OPTIONS requests must be handled — some Express route definitions catch OPTIONS before the cors middleware; ensure cors() is applied globally before route handlers
- ⚠ cors middleware does NOT protect against server-to-server requests — CORS is browser enforcement only; a curl or server-side request bypasses CORS entirely
- ⚠ Dynamic origin validation with a function: origin callback must call callback(null, true/false) — forgetting to call the callback leaves the request hanging
- ⚠ cors package is minimally maintained — it works but receives few updates; for new projects consider framework-native CORS handling which may be more actively maintained
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for cors (Express CORS middleware).
Scores are editorial opinions as of 2026-03-06.