Web browsers, for security and privacy reasons, prevent documents in different domains from affecting each other; that is, cross-site scripting is disallowed.
While this is an important security feature, it prevents pages from different domains from communicating even when those pages are not hostile. This section introduces a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.
The task source for the tasks in cross-document messaging is the posted message task source.
This section is non-normative.
For example, if document A contains an iframe
element that contains document B, and script in document A calls
postMessage()
on the
Window
object of document B, then a message event will
be fired on that object, marked as originating from the
Window
of document A. The script in document A might
look like:
var o = document.getElementsByTagName('iframe')[0]; o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
To register an event handler for incoming events, the script
would use addEventListener()
(or similar
mechanisms). For example, the script in document B might look
like:
window.addEventListener('message', receiver, false); function receiver(e) { if (e.origin == 'http://example.com') { if (e.data == 'Hello world') { e.source.postMessage('Hello', e.origin); } else { alert(e.data); } } }
This script first checks the domain is the expected domain, and then looks at the message, which it either displays to the user, or responds to by sending a message back to the document which sent the message in the first place.
Use of this API requires extra care to protect users from hostile entities abusing a site for their own purposes.
Authors should check the origin
attribute to ensure
that messages are only accepted from domains that they expect to
receive messages from. Otherwise, bugs in the author's message
handling code could be exploited by hostile sites.
Furthermore, even after checking the origin
attribute, authors
should also check that the data in question is of the expected
format. Otherwise, if the source of the event has been attacked
using a cross-site scripting flaw, further unchecked processing of
information sent using the postMessage()
method could
result in the attack being propagated into the receiver.
Authors should not use the wildcard keyword (*) in the targetOrigin argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message is only delivered to the recipient to which it was intended.
Authors who accept messages from any origin are encouraged to consider the risks of a denial-of-service attack. An attacker could send a high volume of messages; if the receiving page performs expensive computation or causes network traffic to be sent for each such message, the attacker's message could be multplied into a denial-of-service attack. Authors are encouraged to employ rate limiting (only accepting a certain number of messages per minute) to make such attacks impractical.
The integrity of this API is based on the inability for scripts
of one origin to post arbitrary events (using dispatchEvent()
or otherwise) to objects in other
origins (those that are not the same).
Implementors are urged to take extra care in the implementation of this feature. It allows authors to transmit information from one domain to another domain, which is normally disallowed for security reasons. It also requires that UAs be careful to allow access to certain properties but not others.
User agents are also encouraged to consider rate-limiting message traffic between different origins, to protect naïve sites from denial-of-service attacks.
postMessage
(message, targetOrigin [, transfer ])Posts a message to the given window. Messages can be structured
objects, e.g. nested objects and arrays, can contain JavaScript
values (strings, numbers, Date
s, etc), and can
contain certain data objects such as File
Blob
, FileList
, and
ArrayBuffer
objects.
Objects listed in transfer are transferred, not just cloned, meaning that they are no longer usable on the sending side.
If the origin of the target window doesn't match the given
origin, the message is discarded, to avoid information leakage. To
send the message to the target regardless of origin, set the
target origin to "*
". To restrict the
message to same-origin targets only, without needing to explicitly
state the origin, set the target origin to "/
".
Throws a DataCloneError
if transfer array contains duplicate objects or if
message could not be cloned.
When posting a message to a Window
of a
browsing context that has just been navigated to a new
Document
is likely to result in the message not
receiving its intended recipient: the scripts in the target
browsing context have to have had time to set up
listeners for the messages. Thus, for instance, in situations where
a message is to be sent to the Window
of newly created
child iframe
, authors are advised to have the child
Document
post a message to their parent announcing
their readiness to receive messages, and for the parent to wait for
this message before beginning posting messages.
When a script invokes the postMessage(message, targetOrigin, transfer)
method (with two or three
arguments) on a Window
object, the user agent must
follow these steps:
If the value of the targetOrigin argument
is neither a single U+002A ASTERISK character (*), a single U+002F
SOLIDUS character (/), nor an absolute URL, then
throw a SyntaxError
exception and abort the overall
set of steps.
Let new ports be an empty array.
Let transfer map be an empty association
list of Transferable
objects to placeholder
objects.
If the method was invoked with a third argument transfer, run these substeps:
If any object is listed in transfer more
than once, or any of the Transferable
objects
listed in transfer are marked as neutered, then
throw a DataCloneError
exception and abort these
steps.
For each object x in transfer in turn, add a mapping from x to a new unique placeholder object created for
x to transfer map, and
if x is a MessagePort
object,
also append the placeholder object to the new
ports array.
Let message clone be the result of obtaining a structured clone of the message argument, with transfer map as the transfer map. If this throws an exception, then throw that exception and abort these steps.
If the method was invoked with a third argument transfer, run these substeps:
Let new owner be the Window
object on which the method was invoked.
For each object x in transfer in turn, obtain a new object y by transferring the object x to new owner, and replace the placeholder object that was created for the object x by the new object y wherever the placeholder exists (i.e. in message clone and in new ports).
Make new ports into a read only array.
Return from the postMessage()
method, but
asynchronously continue running these steps.
If the targetOrigin argument is a single
literal U+002F SOLIDUS character (/), and the
Document
of the Window
object on which
the method was invoked does not have the same origin
as the entry script's document, then abort these steps silently.
Otherwise, if the targetOrigin argument is
an absolute URL, and the Document
of the
Window
object on which the method was invoked does
not have the same origin as targetOrigin, then abort these steps silently.
Otherwise, the targetOrigin argument is a single literal U+002A ASTERISK character (*), and no origin check is made.
Create an event that uses the MessageEvent
interface, with the event name message
, which does not bubble, is
not cancelable, and has no default action. The data
attribute must be
initialized to the value of message clone, the
origin
attribute must
be initialized to the Unicode serialization of the origin of
the script that invoked the method, the source
attribute must be
initialized to the script's global object's
WindowProxy
object, and the ports
attribute must be
initialized to the new ports array.
Queue a task to dispatch the event created in the
previous step at the Window
object on which the
method was invoked. The task source for this task is the posted message task
source.
This section is non-normative.
To enable independent pieces of code (e.g. running in different browsing contexts) to communicate directly, authors can use channel messaging.
Communication channels in this mechanisms are implemented as two-ways pipes, with a port at each end. Messages sent in one port are delivered at the other port, and vice-versa. Messages are asynchronous, and delivered as DOM events.
To create a connection (two "entangled" ports), the MessageChannel()
constructor is called:
var channel = new MessageChannel();
One of the ports is kept as the local port, and the other port is
sent to the remote code, e.g. using postMessage()
:
otherWindow.postMessage('hello', 'http://example.com', [channel.port2]);
To send messages, the postMessage()
method on
the port is used:
channel.port1.postMessage('hello');
To receive messages, one listens to message
events:
channel.port1.onmessage = handleMessage; function handleMessage(event) { // message is in event.data // ... }
Data sent on a port can be structured data; for example here an array of strings is passed:
port1.postMessage(['hello', 'world'], 'http://example.com');
This section is non-normative.
Ports can be viewed as a way to expose limited capabilities (in the object-capability model sense) to other actors in the system. This can either be a weak capability system, where the ports are merely used as a convenient model within a particular origin, or as a strong capability model, where they are provided by one origin provider as the only mechanism by which another origin consumer can effect change in or obtain information from provider.
For example, consider a situation in which a social Web site
embeds in one iframe
the user's e-mail contacts
provider (an address book site, from a second origin), and in a
second iframe
a game (from a third origin). The outer
social site and the game in the second iframe
cannot
access anything inside the first iframe
; together they
can only:
iframe
to a new
URL, such as the same URL but with a
different fragment identifier, causing the Window
in
the iframe
to receive a hashchange
event.iframe
, causing the Window
in the iframe
to receive a resize
event.message
event to
the Window
in the iframe
using the window.postMessage()
API.The contacts provider can use these methods, most particularly
the third one, to provide an API that can be accessed by other
origins to manipulate the user's address book. For example, it could
respond to a message "add-contact Guillaume Tell
<tell@pomme.example.net>
" by adding the given person and
e-mail address to the user's address book.
To avoid any site on the Web being able to manipulate the user's contacts, the contacts provider might only allow certain trusted sites, such as the social site, to do this.
Now suppose the game wanted to add a contact to the user's address book, and that the social site was willing to allow it to do so on its behalf, essentially "sharing" the trust that the contacts provider had with the social site. There are several ways it could do this; most simply, it could just proxy messages between the game site and the contacts site. However, this solution has a number of difficulties: it requires the social site to either completely trust the game site not to abuse the privilege, or it requires that the social site verify each request to make sure it's not a request that it doesn't want to allow (such as adding multiple contacts, reading the contacts, or deleting them); it also requires some additional complexity if there's ever the possibility of multiple games simultaneously trying to interact with the contacts provider.
Using message channels and MessagePort
objects,
however, all of these problems can go away. When the game tells the
social site that it wants to add a contact, the social site can ask
the contacts provider not for it to add a contact, but for the
capability to add a single contact. The contacts provider
then creates a pair of MessagePort
objects, and sends
one of them back to the social site, who forwards it on to the game.
The game and the contacts provider then have a direct connection,
and the contacts provider knows to only honor a single "add contact"
request, nothing else. In other words, the game has been granted the
capability to add a single contact.
This section is non-normative.
Continuing the example from the previous section, consider the
contacts provider in particular. While an initial implementation
might have simply used XMLHttpRequest
objects in the
service's iframe
, an evolution of the service might
instead want to use a shared
worker with a single WebSocket
connection.
If the initial design used MessagePort
objects to
grant capabilities, or even just to allow multiple simultaneous
independent sessions, the service implementation can switch from the
XMLHttpRequest
s-in-each-iframe
model to
the shared-WebSocket
model without changing the API at
all: the ports on the service provider side can all be forwarded to
the shared worker without it affecting the users of the API in the
slightest.
[Constructor] interface MessageChannel { readonly attribute MessagePort port1; readonly attribute MessagePort port2; };
MessageChannel
()Returns a new MessageChannel
object with two new MessagePort
objects.
port1
Returns the first MessagePort
object.
port2
Returns the second MessagePort
object.
When the MessageChannel()
constructor is called, it must run the following algorithm:
Create a new MessagePort
object
owned by the script's global object, and let port1 be that object.
Create a new MessagePort
object
owned by the script's global object, and let port2 be that object.
Entangle the port1 and port2 objects.
Instantiate a new MessageChannel
object, and
let channel be that object.
Let the port1
attribute of the channel object be port1.
Let the port2
attribute of the channel object be port2.
Return channel.
This constructor must be visible when the script's global
object is either a Window
object or an object
implementing the WorkerUtils
interface.
The port1
and
port2
attributes
must return the values they were assigned when the
MessageChannel
object was created.
Each channel has two message ports. Data sent through one port is received by the other port, and vice versa.
interface MessagePort : EventTarget { void postMessage(any message, optional sequence<Transferable> transfer); void start(); void close(); // event handlers [TreatNonCallableAsNull] attribute Function? onmessage; }; MessagePort implements Transferable;
postMessage
(message [, transfer] )Posts a message through the channel. Objects listed in transfer are transferred, not just cloned, meaning that they are no longer usable on the sending side.
Throws a DataCloneError
if transfer array contains duplicate objects or the
source or target ports, or if message could
not be cloned.
start
()Begins dispatching messages received on the port.
close
()Disconnects the port, so that it is no longer active.
Each MessagePort
object can be entangled with
another (a symmetric relationship). Each MessagePort
object also has a task source called the port
message queue, initially empty. A port message
queue can be enabled or disabled, and is initially
disabled. Once enabled, a port can never be disabled again (though
messages in the queue can get moved to another queue or removed
altogether, which has much the same effect).
When the user agent is to create a new
MessagePort
object owned by a script's
global object object owner, it must
instantiate a new MessagePort
object, and let its owner
be owner.
When the user agent is to entangle two
MessagePort
objects, it must run the following
steps:
If one of the ports is already entangled, then disentangle it and the port that it was entangled with.
If those two previously entangled ports were the
two ports of a MessageChannel
object, then that
MessageChannel
object no longer represents an actual
channel: the two ports in that object are no longer entangled.
Associate the two ports to be entangled, so that they form
the two parts of a new channel. (There is no
MessageChannel
object that represents this
channel.)
When the user agent is to clone a port original port, with the clone being owned by owner, it must run the following steps, which return
a new MessagePort
object. These steps must be run
atomically.
Create a new MessagePort
object
owned by owner, and let new
port be that object.
Move all the events in the port message queue of original port to the port message queue of new port, if any, leaving the new port's port message queue in its initial disabled state.
If the original port is entangled with another port, then run these substeps:
Let the remote port be the port with which the original port is entangled.
Entangle the remote port and new port objects. The original port object will be disentangled by this process.
Return new port. It is the clone.
To transfer a MessagePort
object old to a new owner owner, a user
agent must clone the old object with the clone being owned by owner, thus obtaining new, must
neuter the old port, and must finally return new.
The postMessage()
method, when called on a port source port, must
cause the user agent to run the following steps:
Let target port be the port with which source port is entangled, if any.
Let new ports be an empty array.
Let transfer map be an empty association
list of Transferable
objects to placeholder
objects.
If the method was invoked with a second argument transfer, run these substeps:
If any object is listed in transfer more
than once, or any of the Transferable
objects
listed in transfer are marked as neutered, then
throw a DataCloneError
exception and abort these
steps.
If any of the objects in transfer are
either the source port or the target port (if any), then throw a
DataCloneError
exception and abort these
steps.
For each object x in transfer in turn, add a mapping from x to a new unique placeholder object created for
x to transfer map, and
if x is a MessagePort
object,
also append the placeholder object to the new
ports array.
Let message clone be the result of obtaining a structured clone of the message argument, with transfer map as the transfer map. If this throws an exception, then throw that exception and abort these steps.
If the method was invoked with a second argument transfer, run these substeps:
Let new owner be the owner of target port, if there is a target
port, or else some arbitrary owner. (This new owner is used when transfering objects below.
If there is no target port, the
Transferable
objects given in the second argument,
if any, are still transfered, but since they are then discarded, it
doesn't matter where they are transfered to.)
For each object x in transfer in turn, obtain a new object y by transferring the object x to new owner, and replace the placeholder object that was created for the object x by the new object y wherever the placeholder exists (i.e. in message clone and in new ports).
Make new ports into a read only array.
If there is no target port (i.e. if source port is not entangled), then abort these steps.
Create an event that uses the MessageEvent
interface, with the name message
, which does not bubble, is not
cancelable, and has no default action.
Let the data
attribute of the event be initialized to the value of message clone.
Let the ports
attribute of the event be initialized to the new
ports array.
Add the event to the port message queue of target port.
The start()
method must enable its port's port message queue, if it
is not already enabled.
When a port's port message queue is enabled, the event loop must use it as one of its task sources.
If the Document
of the port's event
listeners' global object
is not fully active, then the messages are lost.
The close()
method, when called on a port local port that is
entangled with another port, must cause the user agents to
disentangle the two ports. If the method is called on a port that is
not entangled, then the method must do nothing.
The following are the event handlers (and their
corresponding event handler
event types) that must be supported, as IDL attributes, by
all objects implementing the MessagePort
interface:
Event handler | Event handler event type |
---|---|
onmessage | message
|
The first time a MessagePort
object's onmessage
IDL attribute
is set, the port's port message queue must be enabled,
as if the start()
method
had been called.
When a MessagePort
object o is
entangled, user agents must either act as if o's
entangled MessagePort
object has a strong reference to
o, or as if o's owner has a
strong reference to o.
Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained.
Of course, if this was to occur on both sides of the channel, then both ports could be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other.
Furthermore, a MessagePort
object must not be
garbage collected while there exists a message in a task
queue that is to be dispatched on that
MessagePort
object, or while the
MessagePort
object's port message queue is
open and there exists a message
event in that queue.
Authors are strongly encouraged to explicitly close
MessagePort
objects to disentangle them, so that their
resources can be recollected. Creating many MessagePort
objects and discarding them without closing them can lead to high
memory usage.