Closed ArthurSonzogni closed 2 years ago
Yeah, this looks like a valid requirement. Every use-case we encountered so far needs delegating to a specific origin, so I don't see any problem with this.
From the spec perspective, do you think this should be a non-normative "recommendation" for developers? Or it should be a strong requirement: our algorithm for window post message can have a step saying something like "return early/fail if the origin option is a wildcard". What do you think?
From the spec perspective, do you think this should be a non-normative "recommendation" for developers? Or it should be a strong requirement: our algorithm for window post message can have a step saying something like "return early/fail if the origin option is a wildcard". What do you think?
Good question! It is already a recommendation for developers.
Adding this into the specification early is usually better, because it is easier to remove requirements later than introducing new ones later if we change opinion.
Okay, I will attempt a pull request to modify our draft spec to say "the postMessage algorithm ignores/fails delegation if origin is *". I will wait a few weeks, in case we have more feedback around this.
Hmm, I closed #17 this morning without realizing it was a duplicate of this issue here!
@ArthurSonzogni I am closing this issue but feel free to reopen it if you think we need more here. Thanks.
Thanks for addressing this!
If website don't use COOP:same-origin, they could, without knowing, have an opener/openee relationship with a malicious window. This relation can remain open a long time, despite several navigations in both windows.
With postMessage, we recommend developers not to use targetOrigin="*". With capability delegation, it might be wise to require it instead of recommending it.