Browsers have established themselves as the IT community's ubiquitous client, even though some still consider their...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
operation feeble for displaying large amounts of data. For better or worse, most applications now a days target the Web -- and with it browsers -- as a primary delivery medium. On a related front, software as a service has also come of age as a preferred design approach. So it is that when a technique influencing both world's emerges, it always serves for some interesting discussion on its potential implications, in this case what I am referring to is the use of Cross-Site XMLHttpRequest.
Currently, the only way in which a browser can access services via XMLHttpRequest outside the domain on its main interface is via a proxy. In other words, any application requiring outside services must first obtain them directly from a serverside application and later funnel them to browsers as though the service originated on the main domain.
Enter Cross-Site XMLHttpRequest, an initiative granting browsers more flexibility in terms of the location a service can reside in. Currently launched as a W3C working draft named Access Control for Cross-Site Requests , this specification is putting forth two access mechanisms that were once not possible between browsers and the services used to fulfill Ajax requests.
The first mechanism consists of adding an HTTP Header named
Acess-Control to a page response, allowing a browser to discern on what other sites it can perform an XMLHttpRequest. For example, say your application made use of a service on cnn.com and you wanted an end-user's browser to perform the service call directly to the site. Under normal circumstances browsers won't allow this, but in browsers supporting cross-site XMLHttpRequest, if your application added the HTTP Header
Access-Control: allow <cnn.com>, then this operation would be possible.
It should also be mentioned that the syntax for
Access-Control can contain multiple domains as well as rules for associating patterns in a domain. For example
Access-Control: allow <*.acmesoft.org> exclude <*.shareware.acmesoft.org> would allow a browser to make an XMLHttpRequest to the main site
acmesoft.org, but not to its
A second mechanism for Cross-Site XMLHttpRequest consists of using a similar syntax to the first method, but based on the use of XML documents. In this case, the supported scenario would consist of delivering an initial XML document to a browser containing a pre-processing instruction: those beneath a document's root tag
<?xml version="1.0"?>, like the following
<?access-control allow="cnn.com" exclude="videos.cnn.com"?>. This in turn would also allow a browser to determine on what other sites' out-of-band calls are permitted.
Important lessons in these new approaches can be learned from technologies like Flash, which have had this avenue open for years. By being an independent environment embedded in a browser, Flash players and their applications have long had the capability to make remote service requests in what is practically an open fashion, but this hasn't stopped its makers from constantly tweaking security policies in Flash's handling of cross-site data loading .
The issue here is that the same features easing access to services on different domains also lend themselves to serious exploitation. Suppose that instead of calling a cross-domain service to update an interface, a cross-domain service is used to execute some type of rogue instruction or send information to an unknown source. In these cases you are exposing users to one of the many variations of cross-site scripting (XSS).
XSS is a serious -- albeit often obscure -- issue that afflicts browser users when they inadvertently execute instructions from a different domain than the one they are visiting. It is by no means new or exclusive to Cross-Site XMLHttpRequest, and is in fact on the security checklist of most mid-size organizations developing and allowing access to Web applications. XSS in itself posses a myriad of variations, so needless to say we can't elaborate on all its particularities, though you can find a few testing resources on the Web like this XSS (cross-site scripting) Cheat Sheet.
Without a doubt Cross-Site XMLHttpRequest can potentially ease the way services are combined to make up application inside a browser -- a technique often referred to as Mashup -- but in an online world already fraught with phishing scams and spyware, perhaps it should be prudent to save end user's from one more potential pitfall in their daily navigation routines. In the end, it will be vendors from both browser and serverside platforms that will have the last say in supporting Cross-Site XMLHttpRequest, though it should be wise to point out that the box for Cross-Site XMLHttpRequest started off with no key for a reason.
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and Web-based software, he blogs regularly on these and other software areas.