A newly opened window having access back to the originating window could allow basic phishing attacks (the `window.opener` object is not `null` and thus `window.opener.location` can be set to a malicious website by the opened page).

For instance, an attacker can put a link (say: "http://example.com/mylink") on a popular website that changes, when opened, the original page to "http://example.com/fake_login". On "http://example.com/fake_login" there is a fake login page which could trick real users to enter their credentials.

## Ask Yourself Whether

- The application opens untrusted external URL.

There is a risk if you answered yes to this question.

## Sensitive Code Example

    <a href="http://example.com/" rel="opener" target="_blank"> <!-- Sensitive -->

    <a href="{{variable}}" rel="opener" target="_blank"> <!-- Sensitive -->

## Compliant Solution

In Chrome 88+, Firefox 79+ or Safari 12.1+ `target=_blank` on anchors implies `rel=noopener` which makes the protection enabled by default.

    <a href="https://example.com/" target="_blank" >

## Exceptions

No Issue will be raised when `href` contains a hardcoded relative url as there it has less chances of being vulnerable. An url is considered hardcoded and relative if it doesn’t start with `http://` or `https://`, and if it does not contain any of the characters {}$()[]

    <a href="internal.html" rel="opener" target="_blank" >

## See

- OWASP - Top 10 2021 Category A5 - Security Misconfiguration
- Reverse Tabnabbing
- CWE - CWE-1022 - Use of Web Link to Untrusted Target with window.opener Access
- OWASP - Top 10 2017 Category A6 - Security Misconfiguration
- https://mathiasbynens.github.io/rel-noopener/