Is it possible to catch CORS errors?

Question

This question is about Cross-Origin resource sharing (CORS, http://www.w3.org/TR/cors/ ).

If an error occurs while executing a CORS request, Chrome (and other AFAIK browsers) logs the error in the error console. An example message might look like this:

XMLHttpRequest cannot load http://domain2.example . The origin of http://domain1.example not allowed using Access-Control-Allow-Origin.

I am wondering if there is a way to programmatically get this error message? I tried to wrap my xhr.send() call in try / catch, I also tried to add an onerror() event handler. None of which receive an error message.

Answer 1

Cm:

• http://www.w3.org/TR/cors/#handling-a-response-to-a-cross-origin-request

... as well as notes in XHR Level 2 about CORS:

• http://www.w3.org/TR/XMLHttpRequest2/

Information is intentionally filtered out.

Edit many months later: The next comment here asked "why"; the anchor in the first link was missing several characters, which made it difficult to see in which part of the document I had in mind.

This security feature is an attempt to avoid disclosing information in HTTP headers that may be sensitive. The W3C CORS link says:

User agents must filter out all response headers other than those that are simple response headers, or the field name does not match the ASCII value for one of the Access-Control-Expose Headers (if any) header values ​​before exposing the response headers to the APIs, defined in the CORS API specifications.

This snippet contains links for a "simple response header" listing Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma. So those are transmitted. The "Access-Control-Expose-Headers" header header allows the remote server to set other headers by listing them there. See the W3C documentation for more information.

Remember that you have one origin - let's say that the web page you downloaded in your browser launched some JavaScript bit - and the script sends a request to another source, which is usually not allowed, as malware can do unpleasant things this way. Thus, the browser that runs the script and performs HTTP requests on its behalf acts as a gatekeeper.

The browser looks at the response from this server of a "different origin", and if it does not seem to be "participating" in CORS, the required headers are missing or distorted - then we are not able to trust. We cannot be sure that the local script works in good faith, because it seems to be trying to contact servers that did not expect you to be connected in this way. Of course, the browser should not “leak” any confidential information from this remote server, simply passing the entire response to the script without filtering, which basically will allow you to resolve the cross-search request. A disclosure vulnerability will be detected.

This can make debugging difficult, but it is a compromise between security and usability, because since the "user" is the developer in this context, security has a significant priority.