Benefit of CORS over cross-domain messaging

Question

CORS and cross-domain messaging look the same to me: they allow communication across domains.

Are there any reasons to use one vs. the other?

Answer 1

First of all you should be aware that CORS is supported by the following browsers: Internet Explorer 8+, Firefox 3.5+, Safari 4+, and Chrome. Please note that IE7 and older versions of Firefox and Safari doesn't support it at all. But event IE8 has some limitations - it doesn't support credentials and "preflight" requests to be sent to the server. In addition, your server should be ready for CORS requests, i.e. some extra work on the server should be performed as well.

Cross-domain messaging by using JSONP or iFrames are more universal in terms of browser support and sometimes even doesn't require extra server-side work.

Answer 2

I believe the spirit of the question was "for doing cross-domain XHR, what are the relative merits and disadvantages of CORS and an iframe+postMessage-based approach?"

Explaining what they are intended for doesn't really help answer that question.

Here I try to answer the question, from the perspective of a service provider who wants to provide "services" (data, behavior) to specific known pages/domains, and needs those domains to be able to "call in" to it.

CORS

• Pros
  • Easy to understand when it works / super-easy on the client (doesn't require any complex logic, a simple XmlHttpRequest/fetch call will do the trick)
• Cons
  • Performance: Up-front round-trip overhead for every new URL (and previously visited one after CORS authorization has expired)
  • Potentially complex / often misunderstood implementation server-side (designating when CORS should should be allowed, handling a specialized verb, etc)
  • Very slightly lower support coverage across browsers (than postMessage): https://caniuse.com/#feat=cors vs https://caniuse.com/#feat=x-doc-messaging

iframe+postMessage

• Pros
  • SameSite cookie handling is not a problem (the thing that crosses the domain boundary is the postMessage call, not the XHR call)
  • Simple server-side implementation (just host a "page" containing your JS code and cross-domain messaging rules; most of the complexity ends up in front-end JS)
• Cons
  • More work on the client; if you provide a service, instead of providing a simple endpoint, you need to deliver an "SDK", a script to be executed in the target page.
  • Potentially complex / often misunderstood implementation client-side (specifying what origins should be allowed to post to you, etc)
  • Possibly higher impact when processing a big message than a big XHR payload arriving?? https://dassur.ma/things/is-postmessage-slow/
  • Potential complexities if you set "X-Frame-Options" to help secure your (service-providing) site - you need to add an exemption for the messaging iframe host "page".

(please adjust/correct/add!)

Answer 3

CORS is for ajax requests or flash requests that flash wouldn't normally allow. For example, if there is no cross-domain policy for domain x, and you retrieve an mp3 file from there via flash for playback, flash will not allow you to read the id3 tags of the mp3 file. For ajax, you flat out cannot make the request if the target server doesn't have a cross-domain policy that allows your domain to make requests.

Cross-domain messaging allows you to communicate with an iframe in the document that is from different origin. For example, if you have youtube video iframe, you may pass a message to that iframe to change volume. Normally no communication wouldn't be possible because the iframe has a different origin, so you could not do anything with the youtube iframe programmatically.

The reasons to use one or another, should be now clear. CORS allows you to request data from another origin while message passing between main window and an iframe is used when you want to communicate with an app that is inside the iframe but is not in the same origin.

A practical example:

1.You have an iframe that has a youtube player.

2.You request some videos to play from youtube data api (CORS, could be JSONP, XHR or whatever).

3.You now pass a cross-domain message to the iframe to start playing any of the video you requested in step #2