#3976 - Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') (on hold)
-
By Adam Edington
- Added
- 3 views
| Identifier | #3976 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') (on hold) |
| Status | Open |
| Tags |
Type: Security (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | This sounds like a useful and simple protection mechanism which may be worth adding to links. |
| Steps to reproduce | |
| Additional information | https://love2dev.com/blog/rel-noopener/ |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
This is actually a bit of a minefield.
On rel="noopener"...
rel="noopener" is implemented in browsers for a couple of years only, i.e. is relatively new.
We do *already* support forcing rel="noopener" in Comcode.
Normally what happens is a user without 'allow_html' privilege will post something using WYSIWYG, then Composr will convert that HTML to Comcode, and then rel="noopener" will be applied.
However, it has increasingly been our policy to greenlight the idea that regular users can be given 'allow_html' privilege and our blacklister in the Comcode compiler would filter out any dangerous HTML like JavaScript (as well as our XSS detector that looks at input).
In this scenario, a *blacklist* is not going to *inject* additional HTML. Nor should we try to make that happen, Comcode is already incredibly complicated.
WHATWG have specified a new policy that target="_blank" links should not have a window.opener to be manipulated:
https://github.com/whatwg/html/issues/4078
And browsers have finished implementing it this year:
https://bugs.chromium.org/p/chromium/issues/detail?id=927340
https://bugzilla.mozilla.org/show_bug.cgi?id=1503681
https://bugs.webkit.org/show_bug.cgi?id=190481
If a link does not have target="_blank" then there will be no window.opener to manipulate, and no issue.
However, a user may put in rel="opener" and workaround this!
We could implement blacklisting in the Comcode compiler for rel="opener".
Probably as a v10 security fix (I don't think it warrants implementing our security response process though, this is relatively specific and minor).
Meanwhile, there is a much more robust approach, a new CSP-like policy COOP:
https://www.chromestatus.com/feature/5432089535053824
(this Chrome link provides links to the specification and implementation status in browsers).
This is not yet implemented in Chromium, but nearly done. It is already implemented in Firefox. Development has not apparently started in webkit.
There is lead time to worry about here.
It is a concern that COOP introduces yet another HTTP header for something pretty minor, but it seems worth it. I'd be for implementing this in v11.
- Blacklist rel="opener"
v11:
- Implement COOP
~v12 (once we can rely on COOP being available):
- Remove rel="opener" blacklist
- Remove rel="noopener" injection in Comcode
Better to just leave our robust handling in there, for now at least.