Web applications can’t simply take data from multiple sources without permission. A Web security mechanism called same-origin policy (SOP) is what keeps, say, a shopping website from accessing a user’s bank account, or a news site from reading a user’s e-mails despite being logged into both sites at once.

CORS, the cross-origin resource sharing specification published by the World Wide Web Consortium (W3C), is what allows Web developers to incorporate client-side data into their apps. The most recent specification was proposed for W3C Recommendation—considered a Web standard—on Dec. 5.

According to Ian Jacobs, W3C’s head of communications, after the review period ends on Jan. 14, “We should see a stable, completed Recommendation in the second half of January.”

“Cross-origin resource sharing provides a way for Web resources to give permission to relax this [SOP] restriction to allow for the creation of interesting mash-ups incorporating content from multiple sources,” said Brad Hill, co-chairman of the W3C Web Application Security Working Group. “A mash-up application can use CORS to work with public data, like apartment listings and maps, and also for data that requires some user-level authorization, like integrating a user’s preferences or calendar into applications hosted by different companies.”

CORS has been in existence since 2005 and can be used with all major browsers. It defines a set of headers that allow the browser and server to communicate about which requests are (and are not) allowed.

“The kind of mash-up applications that CORS enables are very compelling and have been a part of the Web for a long time, but before CORS they were built using methods like server-side proxying or JSONP that weren’t very secure,” Hill said.

“CORS lets developers build mash-ups using the familiar XMLHttpRequest API, without having to do proxying, without sharing credentials directly between sites, and it protects mash-up applications from the cross-site scripting risks inherent in JSONP.”

CORS is a standard mechanism allowing the browser and server to communicate requests. It can also request public resources with no access controls such as weather data, census information or similar data, which can be sent using an “Access-Control-Allow-Origin: *” header. Hill added that developers should read the security section carefully, but that CORS should “just work” in the normal way XMLHttpRequest is used.

“If you’re currently exposing Web APIs using JSONP or building integrations by including cross-origin scripts, you really should consider migrating to CORS for a more secure experience,” Hill said.