Hey, thanks for shining in. Adding this flag probably isn’t needed nowadays, all modern browsers, and by that I mean Firefox, Chrome-based, Webkit-based at least browsers, have implemented automatic mitigations for several years now (a quick googling told me 2021 for the latest).
However, it does not harm to write it explicitly, it’s an easy fix, and if that helps with some scanners, I will create a new issue and implement it quickly.
I’ve shipped a fix (v1.29.1, it is pushed but will be available in about 6h until the security review from the WP team is done) that adds rel=”noopener noreferrer” to all of OpenPorte’s own links that open in a new tab.
There are two more instances of the same pattern inside the ALTCHA widget script OpenPorte bundles (a third-party open-source library, not code we maintain). I’ve reported it to that project so it gets fixed at the source rather than patched locally (see altcha-org/altcha issue #198). In practice, this isn’t something an attacker can exploit, modern browsers have applied the relevant protection to target="_blank" links automatically for several years, but I understand it can still trip automated scanners, and I’m tracking a proper upstream fix.
I’m marking this thread as resolved, although we need to wait for altcha’s fix.
Hey, good news, Altcha fixed the reported bug and provided a new release v3.2.3. However, OpenPorte is still on the v2 branch of Altcha. We plan on upgrading the widget to the v3 branch in our next major release, but I have no concrete date yet when that could happen.
