我正在使用 react 構建一個前端應用程式，我想知道https://myapi.com/v1/getitems在 GitHub 上公開 API 端點 URL（例如：）是否有風險，假設端點具有幾個未公開的安全措施，例如CORS和JWT Token Bearer Authentication。我假設不會，因為如果有人要使用端點并發送請求，他們將需要一個令牌并被 CORS 允許這樣做。
這樣做有什么安全風險嗎？
uj5u.com熱心網友回復：
是的。不要在 github 上以普通視圖添加 api 的基本 url。即使您可能擁有CORSand Authorization，但這并不能阻止惡意行為者繼續向您的后端發送垃圾郵件。
您所做的是在根檔案夾中創建一個 .env 檔案。您可以使用類似的庫@beam-australia/react-env，也可以使用其他庫。
您在 .env 檔案中添加對您的環境很重要且通常是機密的值，并且您希望它們在您的代碼中不可見。你這樣做：
API_URL="https://myapi.com/v1"
然后你在你的代碼中訪問這個變數env("API-URL")（在這種@beam-australia/react-env情況下，但其他庫的作業方式相同）。請記住，您需要添加.env，.gitignore以便 .env 檔案不會推送到 github。
關于請求，您可以像這樣進行：
fetch(`${env("API_URL}/getitems`)
這樣，您的代碼將被剝離 API 的基本 url，如果有人看到您的代碼，它將只看到端點，而不是完整的 url。
uj5u.com熱心網友回復：
發布 API 的代碼本身就有風險。有人可以在其中找到漏洞并立即破解它。如果將 API 的地址添加到代碼中，則有助于這種攻擊。他們可以通過一些調查獲得地址；OSINT 和社會工程也是如此，但更好地減少攻擊面。
至于秘密，他們絕不能靠近代碼，因為您或其他開發人員可能會意外地發布它。許多開發人員發生了太多次，所以最好認真對待這一點。如果您想保密地址，則必須從代碼中提取它并將其放入生產環境的配置中，該配置是從與您的代碼完全不同的位置匯入的。使用 Alex 建議的環境變數是一個好主意。現在使用docker很常見，它有一種管理秘密的方法，所以你不需要重新發明輪子：https ://docs.docker.com/engine/swarm/secrets/配置屬于實際實體的另一方面。在 OOP 術語中，您想在其類或全域變數中描述物件的注入屬性，這是一種反模式。
對于客戶端 REST 客戶端，例如在瀏覽器中運行的 javascript 應用程式或 Android/iOS 應用程式，您不得將您的秘密與 REST 客戶端一起發布，否則它不再是秘密。在這種情況下，您需要一個用于 REST 客戶端的服務器端部分，例如使用密鑰對 JWT 進行簽名和加密。REST 客戶端的此服務器端部分是否將 HTTP 請求發送到 REST API 由您決定，在這種情況下，您可以隱藏 REST API 的 URI，或者它只管理 JWT 和 REST 客戶端的客戶端部分發送它。如果 REST 客戶端的服務器端部分將 HTTP 請求發送到 REST API，那么您甚至可以在客戶端和 REST 客戶端的服務器端部分之間使用帶有會話 cookie 的傳統會話，但是您不能在 REST 客戶端的服務器端部分和通信必須是無狀態的 REST API 之間使用它們。盡管在這種情況下如果您沒有多個不同的 REST 客戶端（例如用于 JS 和 JSless 瀏覽器的瀏覽器客戶端、Android 和 iOS 客戶端、在服務器上運行的全自動客戶端等），那么擁有單獨的 REST API 沒有多大意義。所以不要混淆 REST 客戶端 - REST API 關系與瀏覽器 - HTTP 服務器關系，因為它們不一定相同。大多數 REST 客戶端在服務器上運行，而不是在瀏覽器中。Android和iOS客戶端，在服務器上運行的全自動客戶端等等。所以不要混淆REST客戶端-REST API關系和瀏覽器-HTTP服務器關系，因為它們不一定相同。大多數 REST 客戶端在服務器上運行，而不是在瀏覽器中。Android和iOS客戶端，在服務器上運行的全自動客戶端等等。所以不要混淆REST客戶端-REST API關系和瀏覽器-HTTP服務器關系，因為它們不一定相同。大多數 REST 客戶端在服務器上運行，而不是在瀏覽器中。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/507636.html
上一篇：Github用新專案更新舊倉庫