What Is CORS? — Cross-Origin Resource Sharing Explained

What Is CORS? — Cross-Origin Resource Sharing Explained

When building web applications, you often need to fetch resources (like JSON, APIs, images, or fonts) from a different domain than your web page originates from. But browsers enforce a security rule — by default, such cross-domain requests are blocked.

That's where CORS (Cross-Origin Resource Sharing) comes in. It is a mechanism that tells browsers: "Yes — this external domain is permitted to share resources with this web page." CORS allows safe cross-origin data sharing while protecting users from potential security risks.

Why Was CORS Introduced?

Browsers follow a policy called "same-origin" that prevents scripts on one domain from fetching data from another domain. This avoids potential malicious behavior, like a third-party site secretly requesting sensitive user data.

But modern web apps often need to interact with remote APIs, third-party services or content from different domains. Without controlled permission — these requests would always be blocked.

CORS provides a controlled way for servers to explicitly allow selected domains to access their resources — balancing flexibility and security.

How CORS Works — Concept & Process

• When a web page tries to fetch data from a different origin (domain/port/protocol), the browser sends a request including the origin of the page.
• The server receiving the request checks: "Is this origin allowed to access resources here?" If yes — it responds with special headers that permit access.
• If the server's response includes the right headers confirming permission, browser allows the resource to be used by the page. Otherwise — request is blocked.
• For certain "complex" requests (like methods other than GET/POST/HEAD, or with custom headers), the browser may send a "preflight" request (an OPTIONS request) first to check if the server accepts such requests.

Key HTTP Headers Used in CORS

When the server wants to allow cross-origin access, it sends back response headers such as:

• Access-Control-Allow-Origin → Specifies which origin(s) are allowed to access the resource (could be a specific origin or wildcard).
• Access-Control-Allow-Methods → Lists allowed HTTP methods (GET, POST, PUT, DELETE, etc.).
• Access-Control-Allow-Headers → Specifies which request headers can be used.
• Access-Control-Max-Age → Indicates how long the permissions are valid (caching preflight result).
• Access-Control-Allow-Credentials → Indicates if credentials (cookies, auth headers) are allowed in cross-origin requests.

These headers tell the browser whether to allow or block the cross-origin request.

When Does Browser Block Requests Without CORS?

Browser will block by default when:

• You attempt to fetch data from a different origin and server does not send proper CORS headers.
• You try to use custom headers, methods (like PUT/DELETE), or send credentials in a cross-origin request without server permission.
• The server response omits necessary CORS headers or explicitly denies cross-origin access.

Common Use Cases for CORS

Web applications use CORS when:

• Frontend and backend are hosted on different domains (e.g. frontend on domain-a.com, API on api.domain-b.com).
• You fetch data from third-party APIs.
• Your website loads remote assets like JSON, fonts, images, or video from external domains.
• You build single-page applications (SPA) that interact with remote services across domains.

Benefits & Importance of CORS

• Enables safe communication between frontend and remote servers while keeping security intact.
• Allows modern web architecture — decoupled frontend and backend, microservices, external APIs.
• Prevents unauthorized cross-site requests and data theft attempts.
• Lets developers decide which domains are allowed — fine-grained control over resource sharing.

Common Problems & How to Fix Them

Issue: Cross-Origin Request Blocked

Fix: Ensure the server sends correct CORS headers (especially Access-Control-Allow-Origin) and allow required methods/headers.

Issue: Preflight Request Fails

Fix: Configure server to handle OPTIONS requests and respond with proper headers for allowed methods and headers.

Issue: Credentials (cookies/auth) not working

Fix: Server must set Access-Control-Allow-Credentials: true and origin must match exactly (wildcard not allowed with credentials).

FAQs – Understanding CORS

1. Is CORS a browser feature or server feature?

CORS involves both. Browser checks origin and enforces restrictions. Server must include correct response headers to allow cross-origin access.

2. Does CORS apply to images, styles, scripts too?

Static resources like images, stylesheets, or scripts loaded in HTML are often allowed. CORS mainly affects resource requests done via scripts (AJAX / fetch calls).

3. What is "preflight request"?

When a request is "complex" (custom headers, methods, credentials), browser first sends an OPTIONS request to ask server permission. Only after server approval, actual request is sent.

4. Can I allow all domains to access my server resources?

Yes — by using wildcard for allowed origin. But it can reduce security. It's safer to allow only trusted domains.

5. Is CORS enough to secure APIs fully?

No — CORS restricts browser-based access. API security should also include authentication, authorization, rate limiting, and secure data handling.