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 (2.10)  

CWE-942: Overly Permissive Cross-domain Whitelist

Weakness ID: 942
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software uses a cross-domain policy file that includes domains that should not be trusted.

Extended Description

A cross-domain policy file ("crossdomain.xml" in Flash and "clientaccesspolicy.xml" in Silverlight) defines a whitelist of domains from which a server is allowed to make cross-domain requests. When making a cross-domain request, the Flash or Silverlight 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.

Therefore, if a cross-domain policy file includes domains that should not be trusted, such as when using wildcards, then the application could be attacked by these untrusted domains.

An overly permissive policy file allows many of the same attacks seen in Cross-Site Scripting (CWE-79). Once the user has executed a malicious Flash or Silverlight application, they are vulnerable to a variety of attacks. The attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. The attacker could send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site.

In many cases, the attack can be launched without the victim even being aware of it.

+ Time of Introduction
  • Implementation
  • Architecture and Design
+ Applicable Platforms



Architectural Paradigms


+ Common Consequences
Access Control

Technical Impact: Execute unauthorized code or commands; Bypass protection mechanism; Read application data; Varies by context

An attacker may be able to bypass the web browser's same-origin policy.

An attacker can exploit the weakness to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. 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.

+ Demonstrative Examples

Example 1

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

Flash crossdomain.xml :

(Bad Code)
<cross-domain-policy xmlns:xsi=""
<allow-access-from domain="*"/>
<allow-access-from domain="*"/>

Silverlight clientaccesspolicy.xml :

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

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.

+ Observed Examples
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.
The default Flash Cross Domain policies in a product allows remote attackers to access user files.
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.
Chain: Adobe Flash Player and earlier does not properly interpret policy files, which allows remote attackers to bypass a non-root domain policy.
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.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Identify and Reduce Attack Surface

Avoid using wildcards in the cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server.

Phases: Architecture and Design; Operation

Strategies: Environment Hardening; Identify and Reduce Attack Surface

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base183Permissive Whitelist
Research Concepts1000
ChildOfWeakness ClassWeakness Class284Improper Access Control
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts1000
+ References
Apurva Udaykumar. "Setting a crossdomain.xml file for HTTP streaming". Adobe. 2012-11-19. <>.
Adobe. "Cross-domain policy for Flash movies". Adobe. <>.
Microsoft Corporation. "HTTP Communication and Security with Silverlight". <>.
Microsoft Corporation. "Network Security Access Restrictions in Silverlight". <>.
Dongseok Jang, Aishwarya Venkataraman, G. Michael Sawka and Hovav Shacham. "Analyzing the Crossdomain Policies of Flash Applications". 2011-05. <>.
+ Content History
Submission DateSubmitterOrganizationSource
2014-06-05MITREInternal CWE Team
Created by MITRE with input from members of the CWE-Research mailing list.

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