I can see two options here.
The first is to just delegate the crypto part to a server, and communicate with it via a HTTP API. This wouldn't involve the JS web crypto API, and perhaps it would violate some of your design criteria.
Second option for communicating across origins is Window.postMessage()
. It let's you send messages and receive responses between different window
objects in different origins. It is largely up to you to enforce security here:
If you do expect to receive messages from other sites, always verify the sender's identity using the origin
and possibly source
properties. Any window (including, for example, http://evil.example.com
) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.
Always specify an exact target origin, not *
, when you use postMessage
to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage
.
Note that an XSS vulnerability in any page you accept messages from will let an attacker post messages to your origin.
postMessage
and which can also be properly secured (verification if input matches expectations). The first line of the body asks about delegating tasks cross-origin which is different to just communication as in the title. And the references you provide are about sharing information between cross-origin iframes in a more formalized way by attaching policies while sharing. It would be more useful if you would describe the actual problem you are trying to solve.cryptography
tag on the question? I cannot see any obvious relation.window.name
andlocation.hash