What are the 3 types of CORS
Table of Contents:
What are the 3 types of CORS
Did you know that your browser constantly protects you from potential dangers lurking on the web? One of the ways it does this is through Cross-Origin Resource Sharing (CORS). CORS is like a gatekeeper, deciding whether a website from one address (origin) is allowed to access resources from a different address. The origin includes the protocol (like http or https), the domain name, as well as the port number where the website is hosted.
By default, browsers have a “same-origin policy.” This policy acts as a protective barrier. It stops scripts from making requests to other domains unless those domains specifically grant permission via CORS headers. This prevents malicious actions, for example, cross-site request forgery, in addition to data theft.
While many explanations of CORS focus on the overall process involving preflight checks as well as simple requests, there are three main kinds of interactions that developers need to know:
- Simple requests
- Preflight requests
- Requests with credentials
These classifications are not always explicitly described as “types” everywhere, but they are well-established in technical resources, such as MDN Web Docs.
Simple Requests
What makes a request “simple”? A simple request is the most basic kind of cross-origin request. To qualify, it must meet certain strict criteria regarding its HTTP method, headers, next to content type. This is what’s allowed:
- HTTP Methods – Only GET, HEAD, or POST are allowed.
- Headers – Only “safe” headers are permitted (e.g., Accept, Accept-Language, Content-Language). Custom headers, such as X-My-Custom-Header, trigger a preflight request.
- Content-Type – If a Content-Type header is used, it can only be one of application/x-www-form-urlencoded, multipart/form-data, or text/plain. This is crucial for POST requests.
If a request meets these requirements, along with there are no event listeners attached to upload events, the browser sends it directly. The server responds with CORS headers, such as Access-Control-Allow-Origin. These headers indicate if cross-origin access is permitted.
Simple requests are straightforward. They don’t require preflight checks. The browser security models view them as low risk. This is an advantage, as it reduces network traffic for regular tasks like fetching data from APIs using GET.
Preflight Requests
What happens when a request isn’t so simple? Preflight requests come into play in more complex situations. These requests require extra security checks beforehand. A preflight request happens automatically when:
- The HTTP method is something other than GET, HEAD, or POST (for instance, DELETE).
- Custom headers that browsers deem unsafe are included.
- The Content-Type header uses values beyond what’s allowed for simple requests (for example, application/json).
Before sending the actual request, the browser sends an OPTIONS HTTP method. It is called a “preflight” request. This preflight request is essentially asking the server for permission. It checks whether the server allows certain methods as well as custom headers before proceeding with anything that might be sensitive.
The server answers with CORS response headers. It specifies accepted origins, methods, headers, etc. Only after receiving this confirmation, does your script go ahead with its original operation. This depends on permissions on both sides.
This two-step process acts as a safeguard. It prevents risky operations from bypassing browser security measures. This is especially important for advanced features across different domains. Explicit permissions are set through header exchanges between the client and backend systems.
For example:
OPTIONS /data.json HTTP/1.1Host: domain-b.comAccess-Control-Request-Method: DELETEAccess-Control-Request-Headers: X-Custom-Token
If the server approves the request through a response with allow-methods and allow-headers, the DELETE action proceeds. If it is not approved, it is blocked.
Requests With Credentials
How do you handle authentication across different origins? This third category deals with authentication using cookies or authorization tokens in outgoing calls made through JavaScript APIs, like fetch() or XMLHttpRequest. These are commonly referred to as “credentials.”
By default, browsers don’t include credentials in cross-site AJAX or fetch calls. This is true even if the user is already logged in, because the session is stored locally.
To enable sending credentials, you need to set a special flag. Set the credentials property to the string value ‘include’ inside the options object. Pass this object as the second argument to the function.
Example:
fetch(‘https://domain-b.com/data.json’, { credentials: ‘include’}).then(response => response.json()).then(data => console.log(data));
When enabled, cookies for the target domain are included with every call, regardless of the same origin policy. This inclusion is subject to rules enforced within browsers.
The server must also respond properly. It should include the Access-Control-Allow-Credentials header set to “true.” It should specify allowed origins. Wildcard asterisks (*) are not permitted.
This is a short summary:
Simple Requests – These requests occur under specific, defined conditions.
- If no extra permission checks are required.
- If everything matches predetermined criteria.
FAQ
What is CORS?
CORS (Cross-Origin Resource Sharing) is a security feature implemented in web browsers to restrict or allow web pages from making requests to a different domain than the one that served the web page.
Why is CORS important?
It helps protect users from malicious attacks like Cross-Site Request Forgery (CSRF) by preventing unauthorized access to sensitive resources.
How do I enable CORS?
You enable CORS by configuring your server to include specific HTTP headers in its responses, such as Access-Control-Allow-Origin. The most basic way is to set the value to *, but this is not secure for production environments.
What is a preflight request?
A preflight request is an OPTIONS request that a browser sends before making a cross-origin request that uses methods other than GET, HEAD, or POST, or that uses custom headers. The server responds to the preflight request to indicate whether the actual request is allowed.
Resources & References:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
- https://konghq.com/blog/learning-center/what-is-cors-cross-origin-resource-sharing
- https://www.moesif.com/blog/technical/api-development/What-is-CORS-Essential-Guide-to-Cross-Origin-Resource-Sharing/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors
- https://blog.sucuri.net/2024/06/cross-origin-resource-sharing.html
