Reputation: 5979
I have a JavaEE project, it is a monolith. The frontend part is developed in GWT. The GWT also loads other single page applications developed in Angular via iFrame.
From security perspective, is there any risk or security concerns if the issued access token is passed from GWT to the iFrame loaded Angular application via windwos.postMessage()
?
(Reason asking it is because both GWT and the iFrame loaded Angular applications need to access the same backend REST API resources)
Upvotes: 0
Views: 65
Reputation: 13077
The PostMessage API has several features to secure a connection, however, they are optional and it is also possible to send unsecured messages as well.
On the sending side, you need to set the targetOrigin to restrict the domain that can receive the message.
iframe.contentWindow.postMessage(‘My Message’, ‘http://example.org:8080’)
Note that to send the message we first have to get reference to the window object of the recipient of the message and our message will only be received by that one destination.
On the receiving end you need to check the message origin.
window.addEventListener(
"message",
(event) => {
if (event.origin !== ‘http://example.org:8080’) return
},
false,
)
The documentation for postMessage on MDN includes the following:
In order for the event to be dispatched, the origin must match exactly (including scheme, hostname, and port). If omitted, then defaults to the origin that is calling the method. This mechanism provides control over where messages are sent; for example, if postMessage() was used to transmit a password, it would be absolutely critical that this argument be a URI whose origin is the same as the intended receiver of the message containing the password, to prevent interception of the password by a malicious third party.
The MDN page also includes additional details about how postMessage is secured.
Upvotes: 0
Reputation: 29198
Using postMessage is vulnerable to XSS threats if your app ever has such vulnerabilities. E.g. malicious code can register a handler that intercepts tokens:
window.addEventListener('message', (evt) => {
console.log(evt);
});
The tokens might then be exfiltrated to a malicious host for a more concerted attack on your APIs. You can partially mitigate that threat with a strong content security policy.
A more secure option is to use HttpOnly cookies which are automatically shared to your iframes, if they are in the same domain as the main window. Yet that type of option has deployment prerequisites.
To reduce the impact of XSS threats, the best practice from OAuth for Browser Based Apps is to use a Backend for Frontend to issue first-party cookies. It requires more up front thinking on domain design though.
Upvotes: 0