Browser security prevents a web page from making AJAX requests to another domain. This restriction is called the same-origin policy, which preempts a malicious site from reading sensitive data from another site. .
Cross Origin Resource Sharing (CORS) is a W3C standard that allows a server to lighten the same-origin policy. Because sometimes you might want to let other sites call your web API, in this case you have to configure CORS policy as per the requirements, so that the server can accept traffic for pre-defined scenarios and reject the calls otherwise.
You might enable the CORS using [EnableCors]
attribute correctly in .Net Web API Project, but still the things don't work as per the expectation. So its important to understand how CORS works.
The CORS specification introduces several new HTTP headers that enable cross-origin requests. If a browser supports CORS, it sets these headers automatically for cross-origin requests; you don't need to do manually in your JavaScript code.
Lets say you are making an AJAX call to the API http://abc.com/api/test
, from the website http://localhost:4201
. Since the Origin header defines the domain of the source website which is making the request, in this case the Origin is http://localhost:4201
Here is an example of a cross-origin request representation:
(In Raw Format)
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: http://abc.com/api/test
Origin: http://localhost:4201
Referer: http://localhost:4201/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
If the server allows the request, it sets the Access-Control-Allow-Origin
response header. The value of this header either matches the Origin header (if the given domain is allowed), or is the wildcard value *
(if any origin is allowed).
(In Raw Format)
content-type: application/javascript
content-length: 678
access-control-allow-origin: *
date: Mon, 16 May 2022 09:31:51 GMT
If the response does not include the Access-Control-Allow-Origin
header, the AJAX request fails, and the browser disallows the request.
Preflight Requests
For some CORS requests, the browser sends an additional request, called a "preflight request"
, before it sends the actual request for the resource.
Browser sends the preflight request in certain conditions. Following are conditions in which the browser will not send the preflight request:
-
The request method is
GET
, HEAD
, or POST
-
The application sends only these request headers:
Accept
, Accept-Language
, Content-Language
, Content-Type
, or Last-Event-ID
(any other request header will cause the browser to send preflight request).
-
Note that this restriction applies to the headers which the application will add to the request by calling
setRequestHeader()
method on the XMLHttpRequest
object. These request headers are called as author request headers
in the CORS specification .
-
The headers set by the browser (like
User-Agent
, Host
, or Content-Length
) are excluded from this restriction.
-
If the
Content-Type
header is set, its value could only be one of the following (any other value for this header will cause the browser to send preflight request):
-
application/x-www-form-urlencoded
-
multipart/form-data
-
text/plain
Here is an example of a preflight OPTIONS request:
(In Raw Format)
OPTIONS http://abc.com/api/test HTTP/2
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: myheader1
Access-Control-Request-Method: GET
Connection: keep-alive
Host: http://abc.com
Origin: http://localhost:4201
Referer: http://localhost:4201/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
As seen in above example request, the pre-flight request uses the HTTP OPTIONS
method. It includes two special headers:
-
Access-Control-Request-Method
: The HTTP method that will be used for the actual request (GET
method in this above example).
-
Access-Control-Request-Headers
: A list of request headers that the application set on the actual request, myheader1
is a custom header set in above example. Note that this does not include headers that the browser sets itself.
Here is an example response, assuming that the server allows the request:
(In Raw Format)
HTTP/1.1 200 OK
Access-Control-Allow-Headers: myheader1
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Mon, 16 May 2022 09:40:05 GMT
The response can include the Access-Control-Allow-Methods
header that lists the allowed methods (not listed in above example). The Access-Control-Allow-Headers
header lists the allowed headers. If the preflight request succeeds (as in above case), then the browser sends the actual request.
References:
Related Post(s):