The product uses a web-client protection
mechanism such as a Content Security Policy (CSP) or
cross-domain policy file, but the policy includes untrusted
domains with which the web client is allowed to
communicate.

If a cross-domain policy file includes domains
that should not be trusted, such as when using wildcards
under a high-level domain, then the application could be
attacked by these untrusted domains. In many cases, the
attack can be launched without the victim even being aware
of it.

Primary

In HTTP/HTTPS, policies such as the Same Origin
Policy prevent web clients from loading resources from
(or making requests to) domains that did not match the
web site's own domain, e.g., Javascript or other code
hosted on third-party servers. These policies are
strictly enforced by browsers and other
products. However, these restrictions can be reduced
using mechanisms that specify other domains that are
allowed to be contacted from the original site, such as
Content Security Policy (CSP) or cross-domain policy files
(e.g., "crossdomain.xml" in Adobe Flash or Reader,
"clientaccesspolicy.xml" in Silverlight, etc.). These
mechanisms define a list of domains from which a client
is allowed to make cross-domain requests. When making a
cross-domain request, the client will first look for the
policy file on the target server. If it is found, and
the domain hosting the application is explicitly allowed
to make requests, the request is made.

Implementation

Architecture and Design
COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.

Confidentiality
Integrity
Availability
Access Control
Execute Unauthorized Code or Commands
Bypass Protection Mechanism
Read Application Data
Varies by Context
With an overly permissive policy file, an attacker may be able to bypass the web browser's same-origin policy and conduct many of the same attacks seen in Cross-Site Scripting (CWE-79). An attacker can exploit the weakness to transfer private information from the victim's machine to the attacker, manipulate or steal cookies that may include session information, create malicious requests to a web site on behalf of the victim, or execute malicious code on the end user systems. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running ActiveX controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Architecture and Design
Operation
Attack Surface Reduction
Define a restrictive Content Security Policy [REF-1486] or cross-domain policy file.

Architecture and Design
Operation
Attack Surface Reduction
Avoid using wildcards in the CSP / cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server.

Architecture and Design
Operation
Environment Hardening
For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server.

These cross-domain policy files mean to allow Flash and Silverlight applications hosted on other domains to access its data:
Flash crossdomain.xml :

<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd"><allow-access-from domain="*.example.com"/><allow-access-from domain="*"/></cross-domain-policy>

Silverlight clientaccesspolicy.xml :

<?xml version="1.0" encoding="utf-8"?><access-policy><cross-domain-access><policy><allow-from http-request-headers="SOAPAction"><domain uri="*"/></allow-from><grant-to><resource path="/" include-subpaths="true"/></grant-to></policy></cross-domain-access></access-policy>

These entries are far too permissive, allowing any Flash or Silverlight application to send requests. A malicious application hosted on any other web site will be able to send requests on behalf of any user tricked into executing it.

CVE-2012-2292
Product has a Silverlight cross-domain policy that does not restrict access to another application, which allows remote attackers to bypass the Same Origin Policy.
https://www.cve.org/CVERecord?id=CVE-2012-2292

CVE-2014-2049
The default Flash Cross Domain policies in a product allows remote attackers to access user files.
https://www.cve.org/CVERecord?id=CVE-2014-2049

CVE-2007-6243
Chain: Adobe Flash Player does not sufficiently restrict the interpretation and usage of cross-domain policy files, which makes it easier for remote attackers to conduct cross-domain and cross-site scripting (XSS) attacks.
https://www.cve.org/CVERecord?id=CVE-2007-6243

CVE-2008-4822
Chain: Adobe Flash Player and earlier does not properly interpret policy files, which allows remote attackers to bypass a non-root domain policy.
https://www.cve.org/CVERecord?id=CVE-2008-4822

CVE-2010-3636
Chain: Adobe Flash Player does not properly handle unspecified encodings during the parsing of a cross-domain policy file, which allows remote web servers to bypass intended access restrictions via unknown vectors.
https://www.cve.org/CVERecord?id=CVE-2010-3636

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CWE Content Team
MITRE
2014-06-05
2.7
2014-06-23
Created by MITRE with input from members of the CWE-Research mailing list.

CWE Content Team
MITRE
2017-11-08
updated Modes_of_Introduction, References, Relationships

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2020-06-25
updated Description, Name

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description, Relationships

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Relationships

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Background_Details, Common_Consequences, Description, Name, Potential_Mitigations, References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Relationships, Weakness_Ordinalities

Jagjeet Singh
Rakuten Kobo Inc.
2022-08-23
4.18
2025-09-09
Suggested new entry for misconfigured CSP allowing JavaScript, leading to changes in CWE-942 to make it more general

Overly Permissive Cross-domain Whitelist
Permissive Cross-domain Policy with Untrusted Domains