Question

92

Is it possible to trap CORS errors?

rated 0 times [ 99] [ 7] / answers: 1 / hits: 34580 / 14 Years ago, sun, january 30, 2011, 12:00:00

This question is related to Cross-Origin Resource Sharing (CORS, http://www.w3.org/TR/cors/).

If there is an error when making a CORS request, Chrome (and AFAIK other browsers as well) logs an error to the error console. An example message may look like this:

XMLHttpRequest cannot load http://domain2.example. Origin http://domain1.example is not allowed by Access-Control-Allow-Origin.

I'm wondering if there's a way to programmatically get this error message? I've tried wrapping my xhr.send() call in try/catch, I've also tried adding an onerror() event handler. Neither of which receives the error message.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

jennie

Add To Favorites

Follow

Total Points: 593

Total Questions: 102

Total Answers: 106

Location: Federated States of Micronesia

Member since Fri, Sep 16, 2022

2 Years ago

answered 14 Years ago benitoh · Accepted Answer

See:

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/

The information is intentionally filtered.

Edit many months later: A followup comment here asked for why; the anchor in the first link was missing a few characters which made it hard to see what part of the document I was referring to.

It's a security thing - an attempt to avoid exposing information in HTTP headers which might be sensitive. The W3C link about CORS says:

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

That passage includes links for simple response header, which lists Cache-Control, Content-Language, Content-Type, Expires, Last-Modified and Pragma. So those get passed. The Access-Control-Expose-Headers headers part lets the remote server expose other headers too by listing them in there. See the W3C documentation for more information.

Remember you have one origin - let's say that's the web page you've loaded in your browser, running some bit of JavaScript - and the script is making a request to another origin, which isn't ordinarily allowed because malware can do nasty things that way. So, the browser, running the script and performing the HTTP requests on its behalf, acts as gatekeeper.

The browser looks at the response from that other origin server and, if it doesn't seem to be taking part in CORS - the required headers are missing or malformed - then we're in a position of no trust. We can't be sure that the script running locally is acting in good faith, since it seems to be trying to contact servers that aren't expecting to be contacted in this way. The browser certainly shouldn't leak any sensitive information from that remote server by just passing its entire response to the script without filtering - that would basically be allowing a cross-origin request, of sorts. An information disclosure vulnerability would arise.

This can make debugging difficult, but it's a security vs usability tradeoff where, since the user is a developer in this context, security is given significant priority.