Alternatives to CORS

There are other ways to work around the same-origin policy. CORS provides better basic security, error handling, preflight, and other methods that make it a superior choice for cross-origin sharing compared to these alternatives

Alternative methods include the following:

• JSON-P
• WebSocket
• window.postMessage

JSON-PJSONP (later dubbed JSON-P, or JSON-with-padding) was proposed in 2005 as a way to use the <script> tag to request data in the JSON format across domains.

The term "padding" refers to a callback function, which is defined as a query parameter attached to the <script> tag. The callback function is defined on the target domain. The <script> tag on the local domain loads a function or service on the target domain. When the script executes, the function on the target domain is called, and the data returned from the target domain is passed to the callback function on the local domain.

There is no official definition or specification for JSON-P.

Example of JSON-P

1. A callback function is defined on the local domain:

   function handle_data(data) {
      // something is done to the data received from the Target Domain
   }

2. A <script> tag on the local domain loads the script (http://targetdomain/web/service) from the target domain and passes the results to the callback function handle_data on the local domain:

   <script type="application/javascript" src="http://targetdomain/web/service?callback=handle_data" </script>

Using JSON-P – limitations and risks

• JSON-P does not use AJAX XHR; therefore, error detection and handling are not possible until the data is passed to the callback function.
• Trust in the target domain is implicit. If the target domain is compromised, the local domain becomes vulnerable as well. JSON-P is subject to cross-site request forgery (CSRF or XSRF) attacks because the <script> tag is not restricted by the same-origin policy. A script tag on a malicious page can request and obtain JSON data of another domain. If the user is authenticated at the endpoint domain, passwords or other sensitive data may get compromised.
• Rosetta flash uses adobe flash player to exploit servers with a vulnerable JSON-P endpoint. It causes the Adobe Flash Player to accept a flash applet as originating from the same domain.

Proposed JSON-P validation standard

The standard would make JSON-P safer.

• Limit the function ("padding") reference of the JSON-P response to a single expression as a function reference or an object property function reference. A single pair of enclosing parentheses should follow the expression, with a valid and parsable JSON object inside the parentheses.

  Examples of safer JSON-P functions are as follows:

  functionName({JSON});

  obj.functionName({JSON});

  obj["function-name"]({JSON});

• Only whitespace or JavaScript comments may appear in the JSON-P response since whitespace and comments are ignored by the JavaScript parser. The MIME-type application/json-p and/or text/json-p must be included in the requesting <script> element. The browser can require that the response must match the MIME-type.

Note

However, MIME-type application/json-p and/or text/json-p are not supported by any browser. CORS is a safer and more robust method than JSON-P for sharing resources across domains with JavaScript.

WebSocket

WebSocket provides full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF (https://tools.ietf.org/html/rfc6455) in 2011, and the WebSocket API is a candidate recommendation by the W3C (http://www.w3.org/TR/websockets/).

WebSocket uses TCP, not HTTP; nor does it use AJAX/XHR.

Socket.io provides a framework to use WebSocket by creating a node.js server for the socket (http://socket.io/).

WebSocket handshakes

The initial handshake over HTTP sets up the connection and communicates the origin policy information.

If the handshake is successful, the data transfer continues via TCP.

WebSocket creates a two-way communication channel, where each side can, independently from the other, send data at will.

WebSocket and cross-domain resource sharing

A cross-domain WebSocket is enabled with the domain (host) header to accept/deny requests.

Risks of using WebSocket for cross-domain resource sharing

• The header can be spoofed. In order to secure the connection, you will need to authenticate the connection by other means.
• The same-origin policy is not observed in WebSocket; therefore, Cross-Site WebSocket Hijacking (CSWSH) is possible.
• WebSocket does not handle standard safeguards that need to be implemented outside of the WebSocket:
  • Authentication
  • Authorization
  • Sanitization of data

The window.postMessage method

The postMessage method is part of the W3c candidate recommendation for HTML5 Web Messaging ().

postMessage allows messages between discrete documents. The documents may include an iframe embedded in a document, or any other window objects.

The postMessage method dispatches MessageEvent in the target window when a script is completed.

postMessage risks and security measures

• Any window can send a message to any other window. An unknown sender can send malicious messages. The sender's identity can be verified using the origin and source properties. If a site you trusted gets compromised, it can send cross-site scripting messages. The syntax of the received message can be verified against an expected pattern.
• A malicious script can spoof the location property of the window and intercept data. Similar to avoiding the wildcard in the Access-Control-Allow-Origin header in CORS, specify an exact target.

Tip

The obvious security measure is not to use postMessage and not to add any event listeners for message events if you don't expect to receive messages.