cors cross-domain javascript

How does Access-Control-Allow-Origin header work?


Apparently, I have completely misunderstood its semantics. I thought of something like this:

  1. A client downloads javascript code MyCode.js from http://siteAthe origin.
  2. The response header of MyCode.js contains Access-Control-Allow-Origin: http://siteB, which I thought meant that MyCode.js was allowed to make cross-origin references to the site B.
  3. The client triggers some functionality of MyCode.js, which in turn make requests to http://siteB, which should be fine, despite being cross-origin requests.

Well, I am wrong. It does not work like this at all. So, I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation

One thing is sure – I still do not understand how am I supposed to use this header.

I have full control of both site A and site B. How do I enable the javascript code downloaded from the site A to access resources on the site B using this header?


I do not want to utilize JSONP.


  • 6

    I’m not sure, but I believe that setting the header this way allows code on site B to fetch http://siteA/MyCode.js.

    – pimvdb

    May 17, 2012 at 13:26

  • 9

    But how??? In order to get the header value one has to fetch the resource first, but the resource is cross-origin and so shouldn’t the browser block the request in the first place?

    – mark

    May 17, 2012 at 13:33

  • 1

    What you described actually resembles another practice, Content Security Policy

    – Alex

    Jun 9, 2016 at 17:03

  • 5

    @mark You don’t have to fetch the resource in order to get the headers. The HTTP HEADER method will return headers-only. And in the case of CORS, a preflight check is done using the HTTP OPTIONS method which doesn’t return the body either. apsillers answer describes this nicely

    – Matthew

    Sep 9, 2016 at 23:50

  • @DrMcCleod The wiki page linked is pretty clear, the Mozilla page however…

    – Déjà vu

    May 4, 2021 at 7:48


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

When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins. (An origin is a domain, plus a scheme and port number.) By default, Site B’s pages are not accessible to any other origin; using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins.

For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:


Modern browsers will not block cross-domain requests outright. If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain. If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest‘s error event and deny the response data to the requesting JavaScript code.

Non-simple requests

What happens on the network level can be slightly more complex than explained above. If the request is a “non-simple” request, the browser first sends a data-less “preflight” OPTIONS request, to verify that the server will accept the request. A request is non-simple when either (or both):

  • using an HTTP verb other than GET or POST (e.g. PUT, DELETE)
  • using non-simple request headers; the only simple requests headers are:
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type (this is only simple when its value is application/x-www-form-urlencoded, multipart/form-data, or text/plain)

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

Supposing that Site A wants to send a PUT request for /somePage, with a non-simple Content-Type value of application/json, the browser would first send a preflight request:

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

Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically; you do not need to add them. This OPTIONS preflight gets the successful response headers:

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

When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled. In other words, a non-simple request whose preflight is successful is treated the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin again for the actual response).

The browsers sends the actual request:

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

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

And the server sends back an Access-Control-Allow-Origin, just as it would for a simple request:


See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.


  • 4

    But MyCode.js cannot reach for site B in the first place! How will this header arrive at the client? BTW, kudos for the light life glider in the avatar.

    – mark

    May 17, 2012 at 13:36

  • 11

    I edited with clarification: the browser actually does perform a network fetch on site B to check the Access-Control-Allow-Origin header, but it might not provide the response to the JS code on site A if the header doesn’t allow site A to have it. (P.S. Thanks 🙂 )

    – apsillers

    May 17, 2012 at 13:41

  • 4

    So why can my browser make an HTTP get request when I type it in the URL and retrieve JSON data but my javascript client cannot?

    – Jwan622

    Jul 12, 2015 at 12:06

  • 36

    @Jwan622 A fundamental “why?” question like that is probably out of scope for this particular answer, which is just about rules & mechanics. Basically, the browser allows you, the human sitting at the computer, see any resource from any origin. It disallows scripts (which could be written by anyone) from reading resources from origins that are different from the origin of the page running the script. Some related questions are and What is the threat model for the same origin policy?

    – apsillers

    Jul 12, 2015 at 17:55

  • 4

    In case of using an authentication, Access-Control-Allow-Origin does not accept the * in some browsers (FF and Chrome AFAIK). So in this case you have to specify the value from the Origin header. Hope that this will help someone.

    – Zsolti

    Sep 9, 2016 at 19:59


Cross-Origin Resource Sharing – CORS (A.K.A. Cross-Domain AJAX request) is an issue that most web developers might encounter, according to Same-Origin-Policy, browsers restrict client JavaScript in a security sandbox, usually JS cannot directly communicate with a remote server from a different domain. In the past developers created many tricky ways to achieve Cross-Domain resource request, most commonly using ways are:

  1. Use Flash/Silverlight or server side as a “proxy” to communicate
    with remote.
  2. JSON With Padding (JSONP).
  3. Embeds remote server in an iframe and communicate through fragment or, refer here.

Those tricky ways have more or less some issues, for example JSONP might result in security hole if developers simply “eval” it, and #3 above, although it works, both domains should build strict contract between each other, it neither flexible nor elegant IMHO:)

W3C had introduced Cross-Origin Resource Sharing (CORS) as a standard solution to provide a safe, flexible and a recommended standard way to solve this issue.

The Mechanism

From a high level we can simply deem CORS is a contract between client AJAX call from domain A and a page hosted on domain B, a typical Cross-Origin request/response would be:

DomainA AJAX request headers

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 blue parts I marked above were the kernal facts, “Origin” request header “indicates where the cross-origin request or preflight request originates from”, the “Access-Control-Allow-Origin” response header indicates this page allows remote request from DomainA (if the value is * indicate allows remote requests from any domain).

As I mentioned above, W3 recommended browser to implement a “preflight request” before submiting the actually Cross-Origin HTTP request, in a nutshell it is an HTTP OPTIONS request:


If foo.aspx supports OPTIONS HTTP verb, it might return response like below:

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

Only if the response contains “Access-Control-Allow-Origin” AND its value is “*” or contain the domain who submitted the CORS request, by satisfying this mandtory condition browser will submit the actual Cross-Domain request, and cache the result in “Preflight-Result-Cache“.

I blogged about CORS three years ago: AJAX Cross-Origin HTTP request


  • This answer made me realize why i was suddenly getting an issue without using this header for POST and GET requests. I had accidently opened the index.html file directly from disk, so the URL the client was accessing on node.js was thought to be cross-domain, while it was simply running on localhost. Accessing via the URL (as one would usually do) “solved” my issue…

    – LuqJensen

    Jan 8, 2017 at 21:06

  • Would a domain in an external network able to communite with a domain on an internal network?

    – Si8

    Mar 31, 2017 at 1:47

  • I have a public fetch API. But some people were telling to enable CORS as it blocks their requests. I know there is an npm package called cors. But I saw that many Public APIs do not have CORS enabled. I also read some articles about the security risks in CORS. I was asking that will it be wrong to enable CORS. Few people are calling the API from the client-side code that is running in the browsers. Any suggestion is gratefully accepted.

    Feb 25 at 6:10


Question is a bit too old to answer, but I am posting this for any future reference to this question.

According to this Mozilla Developer Network article,

A resource makes a cross-origin HTTP request when it requests a resource from a different domain, or port than the one which the first resource itself serves.

enter image description here

An HTML page served from makes an <img> src request for
Many pages on the web today load resources like CSS stylesheets, images and scripts from separate domains (thus it should be cool).

Same-Origin Policy

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts.
For example, XMLHttpRequest and Fetch follow the same-origin policy.
So, a web application using XMLHttpRequest or Fetch could only make HTTP requests to its own domain.

Cross-Origin Resource Sharing (CORS)

To improve web applications, developers asked browser vendors to allow cross-domain requests.

The Cross-Origin Resource Sharing (CORS) mechanism gives web servers cross-domain access controls, which enable secure cross-domain data transfers.
Modern browsers use CORS in an API container – such as XMLHttpRequest or Fetch – to mitigate risks of cross-origin HTTP requests.

How CORS works (Access-Control-Allow-Origin header)


The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission.

Although some validation and authorization can be performed by the server, it is generally the browser’s responsibility to support these headers and honor the restrictions they impose.


  1. The browser sends the OPTIONS request with an Origin HTTP header.

    The value of this header is the domain that served the parent page. When a page from attempts to access a user’s data in, the following request header would be sent to


  2. The server at may respond with:

    • An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed.
      For example:


    • An error page if the server does not allow the cross-origin request

    • An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains:

      Access-Control-Allow-Origin: *


  • 2

    How to set none are allowed to acees some thing like Access-Control-Allow-Origin:null

    Aug 25, 2017 at 6:18

  • 3

    When I don’t want to allow anyone to access my resources through CORS, what value should I set for Access-Control-Allow-Origin ? I mean the negation of Access-Control-Allow-Origin: *

    Aug 31, 2017 at 13:54

  • 7

    Just dont set anything, for that purpose


    Aug 31, 2017 at 13:56

  • where I put access-control

    – Ganesan J

    Feb 16, 2021 at 11:36

  • I your web server is Apache, then you may put in your http-config or htaccess files


    Feb 16, 2021 at 11:42