Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  

CWE-1022: Improper Restriction of Cross-Origin Permission to window.opener.location

Weakness ID: 1022
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The web application does not restrict or incorrectly restricts modification of its window opener object's location property by an external application from a different origin.
+ Extended Description
By default, many browsers that open a link to an external application with a target specified as a new window/tab provide cross-origin access to the location property via a window.opener object. This enables the external application to choose a location to redirect the calling web application, e.g. for a phishing attack.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
ChildOfBaseBase266Incorrect Privilege Assignment
+ Relevant to the view "Development Concepts" (CWE-699)
MemberOfCategoryCategory442Web Problems
ChildOfBaseBase266Incorrect Privilege Assignment
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Architecture and DesignThis weakness is introduced during the design of an application when the architect does not specify that a linked external document should not be able to alter the location of the calling page.
ImplementationThis weakness is introduced during the coding of an application when the developer does not include the noopener value for the rel attribute.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.


JavaScript (Often Prevalent)


Web Based (Often Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.


Technical Impact: Alter Execution Logic

The user may be redirected to an untrusted page that contains undesired content or malicious script code.
+ Likelihood Of Exploit
+ Demonstrative Examples

Example 1

In this example, the application opens a link in a named tab without taking precautions to prevent the called page from tampering with the calling page's location in the browser.

There are two ways that this weakness is commonly seen. The first is when an <a> tag is used with target="_blank".

(bad code)
Example Language: HTML 
<a href="document.html" target="_blank">

In this scenario, a malicious application could use JavaScript to change the calling application's location property and redirect it to an undesired page. A truly malicious use of this weakness would be to redirect the application to a page that mimics the look and feel of the original application and convinces the user to re-enter authentication credentials.

(attack code)
Example Language: JavaScript 
window.opener.location = '';

To mitigate this type of weakness, some browsers support the "rel" attribute with a value of "noopener" which sets the window.opener object equal to null. Another option is to use the "rel" attribute with a value of "noreferrer" which in essence does the same thing.

(good code)
Example Language: HTML 
<a href="document.html" target="_blank" rel="noopener noreferrer">

A second way that this weakness is commonly seen is when opening a new application directly within JavaScript. In this case, a new application is opened using the function.

(bad code)
Example Language: JavaScript 
var newWindow ="", "_blank");

To mitigate this, set the window.opener object to null.

(good code)
Example Language: JavaScript 
var newWindow ="", "_blank");
newWindow.opener = null;
+ Potential Mitigations

Phase: Architecture and Design

Specify in the design that any linked external document must not be granted access to the location object of the calling page.

Phase: Implementation

When creating a link to an external document using the <a> tag with a defined target, for example "_blank" or a named frame, provide the rel attribute with a value "noopener".

If opening the external document in a new window via javascript, then reset the opener by setting it equal to null.

+ References
[REF-39] Alex Yumashev. "Target="_blank" - the most underestimated vulnerability ever". 2016-05-04. <>.
[REF-40] Ben Halpern. "The target="_blank" vulnerability by example". 2016-09-11. <>.
+ Content History
Submission DateSubmitterOrganization
2017-09-26David Deatherage

More information is available — Please select a different filter.
Page Last Updated: January 18, 2018