啓用CORS支持REST API

我想了解爲什麼許多開發人員在其REST API產品中默認禁用CORS？安全是主要關心的問題？從W3C wiki article上CORS支持，它看起來是相當簡單的添加CORS的支持（添加頁眉訪問控制允許來源值爲「*」在服務器上）啓用CORS支持REST API

最近我遇到了問題時，試圖編寫一個簡單的僅用於JavaScript的應用程序來訪問Azure表和其他Rest API，如Panoptix和ProductWIKI。他們有一些很棒的REST API，但不允許CORS。特定的Azure表具有與其REST API調用相關的嚴格身份驗證過程，儘管它不會讓CORS（至少現在是這樣）。

我想聽聽RESTFul APIs的開發人員和管理員關於他們爲您的API產品啓用/禁用CORS的原因嗎？安全/流量/兼容性是主要關心的問題還是還有其他更多？

來源

2013-01-11 infinity

我對這個問題有興趣從服務器端。對於我設置的服務API，我通常添加CORS，僅僅是因爲它打開了從瀏覽器使用API的大門。但我想知道安全考慮是什麼。我的觀點是，CORS隻影響瀏覽器，只會打敗他們的同源策略，所以黑客可能會拋出一個簡單的代理服務器，並打敗CORS。但是我從安全角度對CORS的態度感興趣。 – Rob

當我創建Web服務時，我離開了CORS，因爲它是默認設置，只有當項目需要公共瀏覽器訪問我們的服務時才添加它。爲什麼同源政策是默認的是另外一個問題。我從來沒有見過阻止來自其他域的Ajax訪問的優勢。

來源

2013-01-11 16:49:00

通過「公共瀏覽器訪問」，你的意思是訪問/無需任何身份驗證。在允許CORS用於需要驗證的REST API時，有什麼我應該考慮的嗎？ – infinity

認證將很重要，但要知道，不支持CORS的Web服務仍然可以公開使用，而不是商業Web瀏覽器。同源政策不過是一個薄弱的花園大門，並沒有提供真正的安全保障。在製作外部Web服務時，我更關心的問題是提高清晰度，文檔，版本和可伸縮性。 –

[CSRF]（https://en.wikipedia.org/wiki/Cross-site_request_forgery）是瀏覽器運行的Web應用程序的一個重要問題。如果我們沒有同源政策，我們可以代表您在您瀏覽我們的網絡應用的同時，在另一個網絡應用上使用您的Cookie來調用Web服務。 –

啓用CORS支持REST API

回答

相關問題