This set of test cases explored whether content from a cross-origin iframe could be dragged and dropped into an editable element in the parent page. The baseline case showed that dragging XML content from a cross-origin frame into a parent textarea was blocked — but variations revealed that certain format combinations circumvented the restriction.
<!-- 01_bypass: plain drop target -->
<iframe src="http://www.iframe.com/crash/08/xml.xml" width="350" height="80"></iframe>
<iframe src="http://www.iframe.com/crash/08/html.html" width="350" height="80"></iframe>
<textarea wrap="off" cols="88" rows="10"></textarea><!-- 02_with_format_FAILS and 03_with_format_SUCCESS: contenteditable drop target -->
<meta http-equiv="X-UA-Compatible" content="IE=9" />
<iframe src="http://www.iframe.com/crash/08/xml.xml" width="500" height="50"></iframe>
<div contenteditable="true">
This is a DIV on the main page...
</div>The investigation showed that dragging XML content from a cross-origin frame into a contenteditable <div> on the parent page could succeed in certain document mode and format combinations, effectively leaking cross-origin content into an attacker-controlled area of the page.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.