Insecure crossdomain.xml Policy files vulnerability

Insecure crossdomain.xml Policy files vulnerability

This article explains the flash insecure crossdomain.xml file and how to protect them against cross-domain requests.


We are going to speak about a very simple traditional vulnerability to find, First let’s get some background details.

Cross-domain XML Files

These files determine which sites are allowed to read resources from a website contains the crossdomain.xml file.

These files is made for flash player, so it is not used directly by the browser itself, this forces us to speak about SOP.

Same Origin Policy

Sop is a concept in web application model , a web browser permits scripts contained in a first web page to access data in a second web page, let me clarify it.

When you are in , this page can request resources from and to , it is known , but can not request to read resources from , so if you have the following JS code .

[code lang=”html”]

<h1> Welcome</h1>

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%3E%0A%0Avar%20xhr%20%3D%20new%20XMLHttpRequest()" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&lt;script&gt;" title="&lt;script&gt;" />

Chrome prevented this action

Banned XHR
Banned XHR

This is not allowed , First your browser issues OPTIONS request , and check if CORS headers allows your website to read resources from Facebook , if Facebook allows your website , CORS headers will contains instructions to permit your website to read Facebook resources.

[code lang=”html”]
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-header1, Content-Type , X-user-id

If facebook sent these headers in the response , this means that :
These instructions tells your browser that your website can request a resource from facebook using POST,GET or Options and the request can contains these headers X-header1, Content-Type , X-user-id

We understand now , SOP and CORS.
Let’s get back to crossdomain.xml file.

Flash player
Flash player is a Component can request any resources you can consider it another browser inside your browser , first if Facebook crossdomain.xml file allows to read it’s resources from your website , by setting your website inside it’s crossdomain.xml file
Which will contains the aforementioned headers.
Flash player will issue a request to Facebook and read resources .

Now here is the weakness.

Many websites allows all websites to read it’s resources via flash. so they are setting their crossdomain.xml file to :


If you see a file with this format , this means that this website is vulnerable to cross-domain requests.

How to test a website

You just need to build a url like and visit it through your browser :
if you found allow-access-from domain=”*” this means it is vulnerable.

Creating a poc , to exploit this weakness , requires to build a swf file , which issues some requests and read it from website , we will settle for notifying the team without any exploit.

Gift users can download and use our simple tool CrossdomainLoader , This tool can test a website for insecure crossdomain.xml file if it is vulnerable , you will be notified by red-marked font .

It will  give you two options , First take a screen-shot for the loaded file , second generate a report contains all details in markdown, you just will need to click submit .

CrossdomainLoader Test Image
CrossdomainLoader Test

Note: The domain used in this POC , is a kayako domain and it was considered as out of scope.


This is a screen-shot of the report generated by the tool .

CrossDomainLoader Report Image
CrossDomainLoader Report

Here is a video explaning what this attack is.



Download Exe & source code

For mac&linux Users

Copy all domains you want to scan in a file , and run the following python script

[code language=”python”]

[code language=”bash”]
python list.txt



Happy hacking.



Please enter your comment!
Please enter your name here