網頁應用上，有一個要注意的地方是同源政策（same-origin policy），請參考 wiki：https://zh.wikipedia.org/zh-tw/%E5%90%8C%E6%BA%90%E7%AD%96%E7%95%A5 ，在網頁技術知識上，mozilla寫得蠻好的：https://developer.mozilla.org/zh-TW/docs/Web/Security/Same-origin_policy

早期IE瀏覽器是允許跨源的，但也延申出很多釣魚，駭客網頁置換網址內容造成許多資安問題。所以現在瀏覽器都已變更為「預設」要求同源，有的設定還藏在很裡面很難改。影響最明顯的，大概就是ajax呼叫不能跨網域。因應也不能叫end user去調整瀏覽器，所以要整合各系統API，看是程式proxy，或者是用http proxy也是有各種解決方案。

這對於單機WEB主機架構是也沒什麼問題，但對於多系統整合，或是前幾年開始紅的微服務就有點麻煩了。現在也有很多現成solution的軟體系統（有收錢）/open source（沒收錢），到處架一架（顧問/代理商要賺錢），一個功能就一個系統/Cluster（N台主機/VM），以前叫程式拼裝車，現在覺得系統拼裝車也不為過…總之苦的都是底層整合，整不起來都是我們的錯QQ。

因每個串接的系統/服務都自己做API，變成常需要到其他系統要資料，或到處 feign（spring cloud），除非所有的服務通通掛成同一個domain name下，但其實又會有些各自的政治與各派的開發看法，難以整合。通常技術上就會用到跨來源資料共用（Cross-Origin Resource Sharing，CORS）來處理，wiki：https://zh.wikipedia.org/zh-tw/%E8%B7%A8%E4%BE%86%E6%BA%90%E8%B3%87%E6%BA%90%E5%85%B1%E4%BA%AB ，mozilla：https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS

開放CORS，資安還是比較有風險，所以能認證就僅量認證，設定越精準越好（不要懶惰直接「」下去，雖然在開發時，都是直接塞沒錯，/遮臉，沒辦法麻，大家都是開發區，頂多只有內部測試區IP可以用而已，那來的domain name…），最後就多做點log紀錄吧，有log才能監控，覺得有問題時才有機會追溯。

CORS的設定，可以用「cors setting recommend」餵Google，可以找到一些不錯的文章，因為這次功能不會用到CORS，就單純介紹這個名詞。如果大型系統/平台整合，或微服務化，可能會需要處理這件事。