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.
A callback function is defined on the local domain:
function handle_data(data) { // something is done to the data received from the Target Domain }A
<script>tag on the local domain loads the script (http://targetdomain/web/service) from the target domain and passes the results to thecallbackfunctionhandle_dataon the local domain:<script type="application/javascript" src="http://targetdomain/web/service?callback=handle_data" </script>
JSON-P does not use AJAX XHR; therefore, error detection and handling are not possible until the data is passed to the
callbackfunction.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.
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-pand/ortext/json-pmust be included in the requesting<script>element. The browser can require that the response must match the MIME-type.
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/).
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.
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 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.
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
locationproperty of the window and intercept data. Similar to avoiding the wildcard in theAccess-Control-Allow-Originheader in CORS, specify an exact target.