CWE-830: Inclusion of Web Functionality from an Untrusted… | Glexia
CWE-830 (Inclusion of Web Functionality from an Untrusted Source) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE…
Glexia's Take · Automated analysis
CWE-830: Inclusion of Web Functionality from an Untrusted Source
Inclusion of Web Functionality from an Untrusted Source represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality Integrity Availability: Execute Unauthorized Code or Commands
Developer Pattern
CWE-830 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-830, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-830: Inclusion of Web Functionality from an Untrusted Source
The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product 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 product 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 product. This weakness is common in "mashup" development on the web, which may include source functionality from other domains. For example, Javascript-based web widgets may be inserted by using '<SCRIPT SRC="http://other.domain.here">' tags, which causes the code to run in the domain of the product, not the remote site from which the widget was loaded. As a result, the included code has access to the local DOM, including cookies and other data that the developer might not want the remote site to be able to access. Such dependencies may be desirable, or even required, but sometimes programmers are not aware that a dependency exists.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- 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: This line of javascript changes the login form's original action target from the original website to an attack site. As a result, if a user attempts to login their username and password will be sent directly to the attack site.
Remediation
- Use safe APIs
- Centralize the control
- Add regression tests
- Review logs and telemetry for attempted abuse
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.