2016-09-15 50 views
0

我以爲SOP在發送前阻止了其他域的所有請求,但是我在我的機器上做了一個簡單的例子,它不是我所期望的:同源策略是否仍允許執行服務器端代碼?

1-我有本地監聽端口8000的服務器將打印發送到/api URL的POST數據。

2-我有另一個本地服務器,用以下腳本提供頁面:fetch('http://localhost:8000/api', {method: 'post', body: 'Sending data.'});。我更改了主機名,在我的瀏覽器中使用foo.com訪問此頁面。

當我訪問foo.com,我的跨域請求被執行,我可以看到在Chrome開發者工具的CORS的錯誤:No 'Access-Control-Allow-Origin' header is present on the requested resource,但在服務器控制檯數據仍然收到。我認爲SOP的存在正好解決了這種問題。它的工作方式,它只保證你不能得到迴應。是這樣嗎?幾乎所有的網絡文件都沒有這麼說。

我錯過了什麼?或者我的例子錯了嗎?

回答

5

就像你說的那樣,這是很多人對同一起源政策的保護以及CORS如何工作的一個很大的誤解。

確實發出請求,服務器處理它並創建響應。只有瀏覽器阻止客戶端訪問結果。這可能很容易讓位給像CSRF這樣的攻擊。

預檢請求也有一定的作用,但該點不會改變,同一個來源策略不會停止請求,它會停止在瀏覽器中到達調用者的響應。

+0

現在我終於可以再次入睡,感謝您的解釋。關於飛行前請求,他們有什麼作用?爲什麼不是所有的'簡單請求',我肯定沒有得到它的價值,因爲主要的觀點是瀏覽器只是爲了阻止響應。延遲問題比通過調用忽略響應的端點更糟糕。 –