本文章同時發佈於:
大家好,是否大家在設計前端時,很常遇到跨來源資源共用 - CORS
的問題呢?
通常這時候我們會趕快去網路Google一下解決方法,以Express.js
為例,我們會安裝cors
這個套件,然後快速的貼到後端的code中,這個問題就解決了。
const express = require('express');
const app = express();
const cors = require('cors');
app.use(cors());
app.post('/', function (req, res) {
res.json({
hello: 'world'
});
});
app.listen(3000, function () {
console.log('App listening on port 3000');
});
但是,你真的清楚自己做了什麼嗎?
到底為什麼會出現CORS,你可能聽說過他是安全機制,但他到底保護了什麼,我們現在的做法會不會有安全疑慮?
是的這非常重要,這也告訴了我們為什麼我們可以在Postman
裡頭呼叫此API卻無法再瀏覽器裡呼叫的原因。
那CORS保護了什麼呢,我以購物平台API Server
、購物平台網頁
、惡意購物網頁
來舉例:
購物平台網頁
,所以瀏覽器存有此網站的Cookie。惡意購物網頁
。購物平台網頁
。此時如果購物平台API Server
已將CORS全開,並且CORS的Access-Control-Allow-Credentials
也有開啟,惡意購物網頁
就可「跨域存取」購物平台網頁
的Cookie將請求送至購物平台API Server
,惡意購物網頁
想買什麼就買什麼。
所以CORS不能胡亂全開。
聽了以上例子,有些人可能會認為CORS是白名單機制,事實不然,
CORS實際是防止「瀏覽器端」被惡意誘導,使得在瀏覽器上做出錯誤行為的機制
就如同上面的例子,讓使用者的Cookie被偷取。
因為他是瀏覽器的安全機制,所以我們使用Postman
才會可以正常呼叫API,因為跟瀏覽器無關
常常聽到有人說透過代理Server
可以解決CORS,但問他們說是怎麼用的時候,時常得到「沒有啊就node-http-proxy我照著一些教學貼貼剪剪就好了」,而他實際代表了什麼?
以下解釋CORS沒有開的API Server
、網頁
、代理Server
的關係:
CORS沒有開的API Server -> 網頁
原本我們是這樣,瀏覽器會顯示CORS錯誤。
CORS沒有開的API Server -> 代理Server來接收Response,並以開啟CORS的方式往下傳 -> 網頁
由於代理Server
「並不是瀏覽器」,所以不會受到CORS沒有開的API Server
的CORS影響。
代理Server
的應用常見的有兩種:
代理Server
在自己的電腦上,讓所有的請求都轉發到此代理Server
來做處理,避開CORS的問題。其他方API
,後端團隊評估後認為沒有CORS的問題後,透過代理Server
來代理請求以避開CORS問題,供前端使用。簡單的來說就是第1個是前端自己架,為「開發時」使用。第2個是後端架設,「可供開發也可供Release使用」
解釋了許多,但其實就只有兩個大重點:
Postman
就可以呼叫API的原因。代理Server
即是透過非瀏覽器的角色的關係來收發API請求,就可避開CORS。謝謝你的閱讀,也歡迎分享指教討論~
API 是如何知道你現在使用的是瀏覽器 or Postman?
用瀏覽器呼叫 API 時有辦法偽裝成 Postman 嗎?