Pourquoi a-t-il été décidé que l'utilisation XMLHTTPRequest pour faire des appels XML ne devrait pas faire des appels à travers la frontière du domaine ? Vous pouvez récupérer du JavaScript, des images, des CSS, des iframes et à peu près tout autre contenu auquel je peux penser à partir d'autres domaines. Pourquoi les requêtes HTTP Ajax ne sont-elles pas autorisées à franchir les limites du domaine ? Cette limitation semble étrange, car la seule façon d'en abuser serait d'injecter du JavaScript dans la page. Toutefois, dans ce cas, il suffirait d'ajouter un élément img, script ou iframe au document pour qu'il demande l'URL du tiers et l'envoie au serveur.
[Edit]
Certaines des réponses indiquent les raisons suivantes, soulignons les raisons pour lesquelles elles ne créent pas une raison majeure pour interdire cela.
XSRF (Cross Site Request Forgery, également connu sous le nom de CSRF, XSRF)
Vous pouvez faire des attaques XSRF sans utiliser cela du tout. En règle générale, XMLHTTPRequest n'est pas utilisé du tout, simplement parce qu'il est très difficile de créer un XMLHTTPRequest compatible avec les principaux navigateurs. Il est beaucoup plus facile d'ajouter une balise img à l'URL si vous voulez qu'ils chargent votre URL.
Publication sur le site d'un tiers
<script type="text/javascript">
$.post("http://some-bank.com/transfer-money.php",
{ amount: "10000", to_account: "xxxx" })
</script>Cela pourrait être accompli avec
<body onload="document.getElementById('InvisbleForm').submit()"
<div style="display:none">
<form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="to_account" value="xxxxx">
</form>
</div>
</body>JPunyon : pourquoi laisser la vulnérabilité dans une nouvelle fonctionnalité ?
Vous ne créez pas plus d'insécurité. Vous ne faites que gêner les développeurs qui veulent l'utiliser pour le bien. Ceux qui veulent utiliser cette fonctionnalité à des fins maléfiques (ou géniales) n'ont qu'à utiliser une autre méthode pour le faire.
Conclusion
Je marque la réponse de bobince comme correct parce qu'il a souligné le problème critique. Comme XMLHTTPRequest vous permet de poster, avec des informations d'identification (cookies) sur le site de destination, et de lire les données renvoyées par le site, tout en envoyant les informations d'identification de la personne, vous pourriez orchestrer un javascript qui soumettrait une série de formulaires, y compris des formulaires de confirmation, avec toutes les clés aléatoires générées qui ont été mises en place pour essayer d'empêcher un XSRF. De cette façon, vous pourriez naviguer sur le site cible, comme une banque, et le serveur web de la banque serait incapable de dire qu'il ne s'agit pas d'un simple utilisateur qui soumet tous ces formulaires.
