Cross-Origin Resource Sharing (CORS)

CORS is a browser security feature that allows websites to securely request resources from different domains. When websites load content such as data or media, they often need to fetch it from a server. Sometimes, this server is not part of the same website — it’s on a different domain. This is called a cross-origin request. However, for security reasons, browsers block certain types of these requests by default.

Cross-Origin Resource Sharing (CORS) is a browser feature that allows servers to say, “It’s okay for other websites to access my resources.” This helps in securely sharing data across different websites. It acts like a gatekeeper, letting servers specify who can access their data and how, while preventing unauthorized cross-site requests.

Same-Origin Policy

The Same-Origin Policy is a security rule implemented by web browsers that prevents a web page from making requests to a different domain than the one that served the web page.

Browsers enforce a same-origin policy that blocks web pages from making requests to domains different from their own. Two URLs are considered same-origin if they share:

• Same protocol (HTTP/HTTPS)
• Same domain name
• Same port number

 

This policy helps protect users by preventing malicious websites from stealing data or performing unwanted actions on another site where the user is logged in. A page from https://example.com cannot freely access data from https://another-domain.com by default. This means, the website loaded from example.com cannot access content or scripts from another-domain.com.

CORS Mechanism

CORS is a way for web servers to relax the Same-Origin Policy. It is implemented through HTTP headers sent by the server. CORS works through HTTP headers that coordinate between browsers and servers:

When a browser sends a cross-origin request (like fetching data from an API on another domain), it checks the response headers to see if that request is allowed.

The key header used in CORS is Access-Control-Allow-Origin. If the server includes this header with the requesting origin, the browser allows the request. For example, if a page from https://myapp.com sends a request to https://api.otherdomain.com, the server at api.otherdomain.com must respond with:

Access-Control-Allow-Origin: https://myapp.com

There are two types of CORS requests:

• Simple Requests
• Preflight Requests

 

Simple Requests

These use standard methods like GET or POST with simple headers. The browser sends the request directly and checks the response.

Preflight Requests

Preflight requests use the OPTIONS method to check if the server permits the actual request. This ensures cross-origin requests are safe. Complex requests (e.g., using custom headers or methods like PUT or DELETE), the browser first sends an HTTP OPTIONS request — called a “preflight” — to ask the server if it’s okay to send the real request. The server must respond with appropriate headers like:

• • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers

If the server allows it, the browser proceeds with the actual request. If not, the browser blocks it for security.

CORS doesn’t replace server-side security. Servers should still validate requests and avoid using wildcard (*) permissions for sensitive data. Proper CORS configuration prevents unauthorized data access while enabling legitimate cross-domain collaboration.