閱讀有關CORS（https://spring.io/understanding/CORS）我已經拿到了下一個疑惑：CORS是一個雙重系統檢查？
由於
CORS是一個雙重檢查安全，無論是在客戶端和服務器，對嗎？
否參見https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS。在https://fetch.spec.whatwg.org/中定義的CORS協議中沒有服務器端檢查。
這是如何在服務器中檢查？
CORS未在服務器端強制執行。瀏覽器是唯一的執行點。服務器只需設置特定的響應頭就可以參與協議。
具體而言，當服務器收到請求時，CORS協議不要求服務器檢查它是否是一個跨源請求。服務器可能會檢查Origin請求標頭的存在，並根據是否找到它或它的值是什麼做不同的事情，但CORS協議不取決於服務器是否執行該操作。此外，CORS協議絕對不要求服務器阻止請求或執行任何其他特定的請求。相反，服務器僅在響應中包含Access-Control-Allow-Origin響應標頭。
瀏覽器總是收到響應，就像通常那樣 - 但如果它們是跨源請求的響應，那麼瀏覽器通過拒絕公開響應前端/客戶端JavaScript代碼來執行CORS協議一個Web應用程序，除非響應包含一個Access-Control-Allow-Origin響應標頭，表明服務器正在選擇允許請求跨源。
不允許跨域請求被使用，因爲我不想從我的Web應用程序以外的地方請求出於安全原因....對吧？
CORS協議不會阻止對任何資源的所有請求。除非您的網絡資源運行在內部網或其他類似防火牆之後，否則任何非瀏覽器工具/應用程序仍然可以訪問您的網絡資源。 CORS不會阻止它們。
對於已經可以通過HTTP無限制公開訪問的Web資源，CORS並不是特別有用。相反，CORS主要用於在Intranet或其他防火牆後面運行的Web資源，並且只有在假定Intranet /防火牆內的任何人都信任的情況下才受基於IP的身份驗證的保護。
CORS的目的是要解決的問題是，當用戶訪問這樣的內部網/防火牆內的任意外部Web應用程序時，該Web應用程序以與用戶相同的權限運行。因此，如果Intranet /防火牆內的Web資源僅基於IP地址信任用戶，那麼在沒有跨源限制的情況下，任何任意外部Web應用程序也會以與用戶相同的權限/信任運行。
如果我不是一個瀏覽器，我不執行任何安全檢查呢？ ...如果我讓一個Java應用程序向http://mywebapp.com/customers發出請求，我可以得到答案，儘管事實上我並不是從原產地http://mywebapp.com:80這個問題，對不對？
是的。 CORS協議沒有做任何限制。
Origin請求頭。 https://fetch.spec.whatwg.org/#http-responses解釋了服務器可以包含（並排除）更詳細的標頭。關於第一個問題，這不是默認實現的嗎？關於第三個問題，如何避免外界的要求？ – user3254515
3.這是您使用身份驗證時。除IP地址外，根據您「信任」您的用戶的內容？ –
「默認實現」假設一個特定的服務器實現，我並不熟悉它們。我假設大多數不會在默認情況下阻止。 – Anne
非常感謝。它很好奇這個「安全」是如何在客戶端（瀏覽器）中實現的，而不是在服務器端，我不明白爲什麼 – user3254515
有關更多解釋，請參閱https://stackoverflow.com/questions/34650915上的最後一段答案。 /它似乎是飛行前爲科斯，並沒有讓人感覺它是一個笑話/ 34668785＃34668785也是答案在https://stackoverflow.com/questions/20164173/is -cors考慮的壞實踐/ 20167528＃20167528。 CORS在客戶端（瀏覽器）中實現，而不是在服務器中實現，原因與瀏覽器中實現[相同來源策略]（https://en.wikipedia.org/wiki/Same-origin_policy）的原因幾乎相同在服務器中。 – sideshowbarker
答案在https://stackoverflow.com/questions/27583161/confusion-over-how-cross-origin-resource-sharing-cors-works/42072894#42072894也是一個很好的解釋 – sideshowbarker