Cross Domain Communication, Same Origin Policy and CORS

In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The term origin is defined using the domain name, protocol, and port number of the HTML document running the script. It has always been possible for the browser to make cross origin requests by specifying a resource from a foreign domain in the IMG, SCRIPT, IFRAME tags etc. But with these requests the client-side script does not have access to the content of this resource, it can only be executed or rendered by the browser.

The same origin policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites. The goal of the policy is to prevent cross-site scripting (XSS), a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users.

With the growing popularity of Ajax, a group of interrelated web development methods used on the client-side to create asynchronous web applications, the same origin policy became more and more a serious drawback. With Ajax, data is usually retrieved using the XMLHttpRequest object.

Various alternatives have been developed to circumvent the same origin security feature, for example :

  • Flash or Silverlight with a  crossdomain.xml policy file
  • iFrame URL Technique
  • JSONP (JSON with padding)
  • XMLHttpRequest Level 2, which has been merged into the main XMLHttpRequest specification in December 2011
  • XDomainRequest (non standard) used by IE 8
  • window.location.hash hack
  • Facebook cross domain communication channel
  • window.postMessage() : supported by Firefox 3, Safari 4, Chrome and IE 8

With HTML 5, a new web browser technology emerged which defines ways for a web server to allow its resources be accessed by a web page from a different domain. This technology is called CORS (Cross-Origin Resource Sharing), a first working draft was published by W3C.

CORS works on a per-page access-control model. Every page has to respond with a special header, the Access-Control-Allow-Origin header to be accessible by a foreign site.In the CORS model the responsibility of Access Control is in the hands of the developers and not the server administrators. One drawback of this technology is that the Access-Control-Allow-Origin header is not yet supported by Amazon AWS S3. A lot of web designers are requesting this feature on the AWS Developer Forum.

The following list gives additional useful links to websites reporting about this topic :

Facebook Graph API and access tokens

The Facebook Graph API enables you to read and write objects and connections (relationships)  in The Facebook social graph.

There are 14 graph objects available :

  1. user
  2. page
  3. group
  4. application
  5. post
  6. status message
  7. note
  8. event
  9. link
  10. checkin
  11. album
  12. photo
  13. video
  14. subscription

Each object has a collection of properties. The numer of properties is ranging from 4 (min) for the “status message” object to 23 (max) for the ” user” object.

Besides the listed objects, which can be connected to other objects, the following additional connections are defined :

  2. feed
  3. picture
  4. tagged
  5. statuses
  6. insights
  7. maybe
  8. invited
  9. attending
  10. declined
  11. members
  13. source
  14. home
  15. friends
  16. activities
  17. interests
  18. music
  19. books
  20. movies
  21. television
  22. inbox
  23. outbox
  24. updates
  25. accounts

Each object has an individual ID (xxxxxxx) and can be accessed with the URL :

A field query parameter can be used to filter the returned data, for instance :,name, picture

Alternatively, the ID can be a name, if defined. The connections, if available, are returned in the same request if the parameter “metadata=1” is added to the request (Introspection). Multiple objects can be fetched in the same request by adding the “?ids=” parameter. A special identifier  “me” refers to the current user.

To fetch a specific connection, for instance who is attending the event zzzzzz, the URL is structured as follows :

All responses are JSON (Javascript Object Notation) objects, a lightweight data-interchange format.

If an object is private, you will receive only the public part of the data or the following error message :

   "error": {
      "type": "OAuthAccessTokenException",
      "message": "An access token is required to request this resource."

To access a graph object with an active access token (yyyyyy), the following method is used :

All calls with access tokens are required to go over HTTPS.

An access token is granted by the concerned user, by the page or by the application. Access tokens are based on OAuth 2.0, an open protocol providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

In an initial launch, Facebook supports three ways of getting an access token :

  • The default authorization flow is the web server flow for use by server-side developers. The whole flow works by redirecting the user to the authorization server (Facebook) and back to the developer site.  A “Connect URL” with the domain and path of the site must be preregistered.
  • The second method is the user-agent flow in a Javascript based application. Because the code actually runs on the client device, it can’t really rely on embedded secret keys for security – in JavaScript, anyone can look at the source code and trivially extract the secret. The access token is just returned directly in the redirect response instead of requiring an extra server call with specific care for handling security issues.
  • The third method, client credentials flow, is the simplest flow – just exchange your client_id and secret for an access token, no user is involved. It’s mainly supported for accessing application-only resources.

The Apache CouchDB Project

Apache CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution. CouchDB provides a RESTful JSON API than can be accessed from any environment that allows HTTP requests.

CouchDB is written in Erlang, a robust functional programming language ideal for building concurrent distributed systems. Erlang allows for a flexible design that is easily scalable and readily extensible.