CORS is a mechanism that uses additional HTTP headers to enable secure cross-origin resource sharing between web apps on different origins.
When web apps have distinct origins, they must follow the CORS mechanism, allowing servers to set specific HTTP headers to communicate permissions for cross-origin requests to the browser.
Before the introduction of CORS
a) In the past, scenarios like vikashk.in attempting to access data or files from another domain, such as google.com/api/getdata, were strictly prohibited. These cross-domain requests were not permitted, hindering vikashk.in from accessing resources hosted on a different domain.
b) In the past, vikashk.in faced restrictions when attempting to make calls to a subdomain like api.vikashk.in. Such cross-origin requests to subdomains were not allowed, limiting vikashk.in is ability to interact with resources hosted on specific subdomains of its own domain or other domains.
c) In the past, vikashk.in encountered limitations when making requests to a different port on its own domain or other domains. For instance, attempting to access vikashk.in:5005, which corresponds to a specific port other than the standard HTTP port (e.g., 80), was not allowed due to cross-origin restrictions.
d) In the past, cross-origin resource sharing did not permit requests from one protocol to another. For instance, attempting to access vikashk.in when the origin was vikashk.in (or vice versa) was not allowed. This restriction prevented secure HTTPS requests from accessing resources on non-secure HTTP origins and vice versa due to potential security risks and privacy concerns.
CORS enables secure cross-origin resource sharing for web apps, promoting seamless communication and resource access. It complements the microservices trend, empowering developers to create sophisticated distributed applications with robust security
How does resource sharing between two applications work?
Suppose we have two apps on different domains, A (origin 1) and B (origin 2). When they want to share resources, CORS comes into play. A, which is requesting something from B, follows the CORS mechanism by initiating a preflight options call before making the actual API call.
In the CORS process, additional HTTP headers are utilized to validate the request's legitimacy. When A initiates the actual CORS call, the browser performs a preliminary options call to B. B's server evaluates the request from A to determine its validity.
If the request from A is deemed valid, B sets specific additional HTTP headers that signal to the client (A) that the request is secure. Following this verification, the actual call and post call are executed, allowing the two apps to share resources seamlessly
What is a Preflight Request?
A preflight request is an initial request sent by the browser as part of the Cross-Origin Resource Sharing (CORS) mechanism. It is sent before making the actual CORS request to check with the server if the actual request is allowed.
What is an Options Call?
An Options call is a method used in a preflight request during Cross-Origin Resource Sharing (CORS). The browser sends this request to the server before making the actual CORS request to determine what methods and headers are allowed for the cross-origin request.
What is the role of additional HTTP headers in the context of CORS?
In CORS, the server includes additional HTTP headers in its response. The most common header is 'Accept-Control-Allow-Origin,' allowing specific domains to access the requested resource.
For public APIs, the server sets 'Accept-Control-Allow-Origin:⭐️ ' , permitting any domain to access it. To restrict access, the server can specify a domain name instead of ⭐️.
If the server sets 'Accept-Control-Allow-Origin: vikashk.in,' only that domain can make the requested call. The preflight call is validated before executing the actual call.
Other relevant HTTP headers include 'Accept-Control-Allow-Methods,' defining allowed HTTP methods like GET, PUT, POST, and various headers to customize CORS behavior.
Do all requests made from A to B follow CORS preflight, or is a preflight call made for every request?
In the context of CORS, not all requests made from A to B follow a preflight call. Instead, there are two types of access-control mechanisms:
Simple Requests: Simple requests, such as standard GET and POST requests with no custom headers, do not trigger preflight calls. The browser handles these requests directly without the need for an additional preliminary call.
Preflight Requests: For certain complex requests, like those involving custom headers or specific HTTP methods, a preflight call is made. The browser initiates this preliminary request to the server to determine if the actual CORS request is allowed before proceeding with the actual call.
Some requests are automatically considered simple by the browser, and it doesn't perform a preflight call before executing them. This is an expected behavior and not an error. To enable smooth and secure cross-origin resource sharing, servers can set the 'Access-Control-Allow-Origin' header to permit such requests.
Developers generally employ the following approaches to deal with CORS:
a) Using Browser Plugins: Some developers use specific plugins or extensions for browsers like Chrome to bypass the CORS filter, allowing cross-origin requests during development. However, this is not recommended for production environments as it can compromise security.
b) Modifying Browser Security Flags: Another workaround is starting Chrome with disabled web security by using certain flags. While this can help during development, it should not be used in production due to security risks.
The best solution is to follow the web CORS standard by configuring the server side properly. Setting headers like 'Access-Control-Allow-Origin' and 'Access-Control-Allow-Methods' ensures secure and controlled cross-origin resource sharing, maintaining a robust security posture and enabling safe interactions between web applications across different origins.