Coder Perfect

What is the purpose of the Access-Control-Allow-Origin header?


Apparently, I misinterpreted its semantics completely. Something along these lines came to mind:

I’m sorry, but I’m mistaken. This isn’t how it works at all. So, I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation

One thing is certain: I’m still baffled as to how I’m expected to use this header.

Both site A and site B are completely under my control. How can I use this header to allow the javascript code downloaded from site A to access resources on site B?


JSONP is not something I wish to use.

Asked by mark

Solution #1

CORS (Cross-Origin Resource Sharing) header Access-Control-Allow-Origin

Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to specific sources when Site A tries to fetch material from Site B. (An origin is comprised of a domain, a scheme, and a port number.) By default, Site B’s pages are inaccessible to any other origin; however, employing the Access-Control-Allow-Origin flag allows particular requesting origins to gain cross-origin access.

Site B should provide its pages with the response header: for each resource/page it wants to make accessible to Site A.


Cross-domain queries will not be blocked outright by modern browsers. When Site A requests a page from Site B, the browser will fetch the requested page across the network and check if Site A is listed as an allowed requester domain in the response headers. The browser will trigger the XMLHttpRequest’s error event and reject the response data to the requesting JavaScript code if Site B has not specified that Site A is allowed to view this page.

What happens at the network level can be a little more complicated than what has been described so far. If the request is “non-simple,” the browser first makes a data-free “preflight” OPTIONS request to ensure that the server will accept it. When either (or both) of the following apply to a request, it is non-simple.

If the server answers to the OPTIONS preflight with response headers that match the non-simple verb and/or non-simple headers (Access-Control-Allow-Headers for non-simple headers, Access-Control-Allow-Methods for non-simple verbs), the browser makes the actual request.

If Site A wants to submit a PUT request to /somePage with a non-simple Content-Type of application/json, the browser will send a preflight request first:

OPTIONS /somePage HTTP/1.1
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

The browser automatically adds Access-Control-Request-Method and Access-Control-Request-Headers; you do not need to add them. The successful response headers are obtained by using the OPTIONS preflight:

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

The behavior is identical to how a basic request is handled when sending the real request (after preflight). In other words, if the preflight is successful, a non-simple request is considered the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin again for the actual response).

The actual request is sent by the browser:

PUT /somePage HTTP/1.1
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

And, just like with a simple request, the server responds with an Access-Control-Allow-Origin:


For additional information on non-simple requests, see Understanding XMLHttpRequest over CORS.

Answered by apsillers

Solution #2

According to Same-Origin-Policy, browsers confine client JavaScript in a security sandbox, and JS cannot directly connect with a remote server from a different domain. CORS (A.K.A. Cross-Domain AJAX request) is an issue that most web developers may encounter. In the past, developers devised a variety of perplexing methods for achieving Cross-Domain resource requests, the most common of which are:

Those complex methods have certain issues, for example, JSONP may result in a security hole if developers simply “eval” it, and #3 above, while it works, both domains should construct rigorous contracts between themselves, as it is neither flexible nor elegant in my opinion:)

Cross-Origin Resource Sharing (CORS) was proposed by the W3C as a standard method to give a safe, flexible, and recommended answer to this problem.

The Mechanism

CORS can be thought of as a contract between a client AJAX call from domain A and a page hosted on domain B at a high level. A example Cross-Origin request/response would be:

AJAX request headers for DomainA

User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115

DomainB response headers

Cache-Control private
Content-Type application/json; charset=utf-8
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

The “Origin” request header “indicates where the cross-origin request or preflight request originates from,” and the “Access-Control-Allow-Origin” response header implies that this page allows remote requests from DomainA (if the value is * indicates that remote requests from any domain).

As previously stated, W3 recommends that browsers do a “preflight request” before submitting the actual Cross-Origin HTTP request, which is an HTTP OPTIONS request in a nutshell:


If foo.aspx supports the OPTIONS HTTP verb, it may respond as follows:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

By satisfying this mandatory condition, the browser will submit the real Cross-Domain request and cache the result in “Preflight-Result-Cache” only if the response has “Access-Control-Allow-Origin” AND its value is “*” or contains the domain who submitted the CORS request.

Three years ago, I wrote a blog post about CORS: Cross-origin HTTP request using AJAX

Answered by Wayne Ye

Solution #3

Although the question is a little old to answer, I am posting it here in case it is asked again in the future.

According to an article on the Mozilla Developer Network,

An img> src request for is made by an HTML page delivered from Many online pages today load resources from several domains, such as CSS stylesheets, pictures, and scripts (thus it should be cool).

Cross-origin HTTP requests initiated from within scripts are restricted by browsers for security reasons. The same-origin policy is followed by XMLHttpRequest and Fetch, for example. As a result, a web application that uses XMLHttpRequest or Fetch can only make HTTP requests within its own domain.

Developers asked browser vendors to allow cross-domain requests in order to improve web applications.

The Cross-Origin Resource Sharing (CORS) method provides web servers with cross-domain access controls, allowing for secure data transfers across domains. To limit the hazards of cross-origin HTTP requests, modern browsers use CORS in an API container like XMLHttpRequest or Fetch.


Answered by Peyman Mohamadpour

Solution #4

My intuition regarding which site hosts the headers is inaccurate whenever I think about CORS, just as you indicated in your inquiry. Thinking about the aim of the same origin policy helps me.

The same origin policy prevents harmful JavaScript on from accessing private information you’ve chosen to share solely with Without the same origin policy, JavaScript written by’s developers may cause your browser to send requests to, which would use your authentication cookies. could thus take the confidential information you disclose with

Working across domains is sometimes necessary, which is where CORS comes in. The Access-Control-Allow-Origin header is used by CORS to list other domains ( that are trusted to run JavaScript that can interact with, hence relaxing the same origin policy for

Consider the following to determine which domain should serve the CORS headers. You go to, which has JavaScript that attempts to send a cross-domain request to It should be up to, not, to decide whether or not it sets CORS headers that relax the same origin policy allowing the JavaScript from to interact with it. If could set its own CORS headers allowing its own JavaScript access to, this would completely nullify the same origin policy.

I think the reason for my bad intuition is the point of view I have when developing a site. It’s my site, with all my JavaScript, therefore it isn’t doing anything malicious and it should be up to me to specify which other sites my JavaScript can interact with. When in fact I should be thinking which other sites JavaScript are trying to interact with my site and should I use CORS to allow them?

Answered by Dom

Solution #5

Join the proxy link to the URL with React and Axios, and add the header as seen below.

+ Your API URL

It will work just by adding the Proxy link, however it will also throw an error for No Access. As a result, it is preferable to include a header, as illustrated below.

axios.get(`[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);

Answered by Dhaval Jardosh

Post is based on