我意識到跨站點腳本的這個問題已經被覆蓋，但是對於web開發來說是新的，我還有一些問題。XMLHttpRequest跨站點腳本？
目前我正在測試我在我的PC上寫入的HTML文件，該文件連接到另一臺機器上的RESTFul Web服務。我得到status=0。這是否被認爲是跨站點腳本？
如果一臺服務器託管一個帶有JavaScript的文件，並且該JavaScript文件有XMLHttpRequest秒到服務器自己的Web服務，那會工作，還是那麼糟糕？
道歉，如果任何這些問題都很愚蠢。
不，這不是跨站點腳本。當從其他服務器包含腳本JS文件時，它將呈現在您的站點中，因此您將無法通過JS腳本最初所在的XMLHttpRequest站點進行訪問。
如果這可能比任何主持jQuery文件的人都有可能，包括谷歌在內的許多服務器都會爲XMLHttpRequests打開。
因此，這是不可能的。
如果你想從另一臺服務器得到JSON響應，你可以使用pjson。谷歌它的更多信息。
和Cross Site Scripting是有人在您的網站上注入JavaScript代碼以繞過訪問控制。
status=0能爲我提供各種各樣的東西，而且不知道更多關於如何達到這一點的信息，要確定它到底意味着什麼是非常困難的。您可能正在使用iframe，另一臺計算機可能真的會告訴您狀態爲0 ...我們不知道。
一般的規則是，它並不重要，其中JS是，它將執行它的加載數據。這就是Google js歸檔api的可能性（你知道，在各種不同的地點使用https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.js）。說實話，這不是一個安全問題。
當js文件嘗試訪問另一個域（甚至是子域）時（無論是通過處理iframe還是通過XMLHTTPRequest），都會出現安全問題。正是在這個時候，瀏覽器纔會在腳本上「打下馬腳」。
因爲這個原因，從硬盤驅動器（file：///）到任何Internet協議（http | https）的JavaScript通信都會遇到困難。
您可以使用CORS。您可以使用現在使用的相同的代碼，但是您通過ajax請求頁面的另一臺服務器必須在該頁面上發送以下標題：
Access-Control-Allow-Origin: http://yoursite.example.com
#or to allow all hosts
Access-Control-Allow-Origin: *
這不是一個愚蠢的問題。 ;-)幾天前我也問過自己。 –