Inclusion of Web Functionality from an Untrusted Source
The software includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the software, potentially granting total access and control of the software to the untrusted source.
Including third party functionality in a web-based environment is risky, especially if the source of the functionality is untrusted.
Even if the third party is a trusted source, the software may still be exposed to attacks and malicious behavior if that trusted source is compromised, or if the code is modified in transmission from the third party to the software.
Such dependencies may be desirable, or even required, but sometimes programmers are not aware that a dependency exists.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
This login webpage includes a weather widget from an external website:
This webpage is now only as secure as the external domain it is including functionality from. If an attacker compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker would have complete control, as seen in any XSS weakness (CWE-79).
For example, user login information could easily be stolen with a single line added to weatherwidget.js:
Weaknesses in this category are related to the design and architecture of the entry points to a system. Frequently these deal with minimizing the attack surface throug...
This view (slice) covers all the elements in CWE.
CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...
This view (slice) lists weaknesses that can be introduced during implementation.