CORS
A browser security mechanism that controls which websites may access resources on other domains (origins) using special HTTP headers.
CORS (Cross-Origin Resource Sharing) is one of the most common stumbling blocks in web development – almost every developer has seen 'Access to fetch has been blocked by CORS policy'. Behind it is an important security mechanism: it stops a malicious site from making API requests to other services in the background and stealing data. Understood and configured correctly, CORS is not an obstacle but a core part of web security.
What is CORS?
CORS is an HTTP-header-based mechanism that lets web servers specify which other origins (protocol + domain + port) may access their resources. Browsers block cross-origin requests by default (same-origin policy). CORS relaxes this in a controlled way: the server uses the Access-Control-Allow-Origin header to list allowed origins. For non-simple requests (e.g. custom headers or PUT/DELETE), the browser sends a preflight (OPTIONS) request first to learn allowed methods and headers. Other CORS headers control whether credentials may be sent, which methods are allowed and how long the preflight result may be cached.
How does CORS work?
When a page on https://app.example.com calls an API on https://api.example.com, the browser applies the same-origin policy: different subdomains are different origins. For simple GET requests the browser sends the request and checks the response’s Access-Control-Allow-Origin. For non-simple requests it first sends an OPTIONS preflight; the server responds with allowed origins, methods and headers. Only if that matches does the browser send the real request. This check happens only in the browser – server-to-server calls are not affected.
Practical Examples
A React app on https://app.firma.de calls an API on https://api.firma.de – CORS must be configured because different subdomains are different origins.
A SaaS product exposes a public API and sets Access-Control-Allow-Origin: * for read-only endpoints but specific origins for write operations.
A developer debugs a CORS error: the API allows the right origin but the custom header X-API-Key is missing from Access-Control-Allow-Headers.
A finance portal uses CORS with credentials (Access-Control-Allow-Credentials: true) to send cookies for auth across subdomains.
A microservice setup uses an API gateway that configures CORS once for all backend services.
Typical Use Cases
Single-page applications: Frontend and backend on different domains or ports must communicate via CORS
Microservices: Services on different subdomains must talk to each other and to the frontend
Public APIs: Third-party sites should be able to access your API in a controlled way
Development: Local frontend (localhost:3000) calling API (localhost:8080)
Embedded widgets: Chat or analytics on other sites that talk to your server
Advantages and Disadvantages
Advantages
- Protection against cross-site abuse: Stops malicious sites from making API requests on behalf of the user
- Granular control: Allowed origins, methods, headers and credentials are configurable
- Browser-native: No extra software – all modern browsers support CORS
- Preflight caching: Preflight responses can be cached to reduce overhead
Disadvantages
- Common source of bugs: Wrong CORS setup is a frequent cause of issues
- Extra latency: Preflight doubles HTTP requests for non-simple requests
- Browser-only: CORS does not protect server-to-server calls – not a replacement for API auth
- Wildcard limits: Access-Control-Allow-Origin: * cannot be used with credentials
Frequently Asked Questions about CORS
Why do I get a CORS error even though my server responds correctly?
Is CORS a security risk?
How do I configure CORS in Node.js/Express?
Related Terms
Want to use CORS in your project?
We are happy to advise you on CORS and find the optimal solution for your requirements. Benefit from our experience across over 200 projects.