security/api-keys 正確性

用途

禁止硬編碼 API 金鑰和其他憑證。

為什麼這樣不好？

將 API 金鑰硬編碼並提交到原始碼控制是一個嚴重的安全風險。

1. 如果您的程式碼洩漏，攻擊者可以使用您的 API 金鑰來存取您的服務和資料。
2. 意外地將 API 金鑰捆綁在一起可能會導致它們在您的網站上公開暴露，從而損害您的服務。
3. 您聘請的任何開發人員或承包商都將有權存取您的服務，即使他們失去存取您程式碼庫的權限也是如此。
4. 即使被刪除，它們也會在您的 git 儲存庫的提交歷史記錄中可見。
5. 金鑰輪換需要程式碼變更和重新部署，因此無法由安全團隊或自動化系統處理。
6. 還有更多原因。

const API_KEY = "abcdef123456";
const data = await fetch("/api/some/endpoint", {
  headers: {
    Authorization: `Bearer ${API_KEY}`,
  },
});

替代方案

警告

Oxc 團隊並非安全專家。我們不認可任何特定的金鑰管理服務或策略。請自行研究並為您的使用案例選擇最佳解決方案/架構。

一個可能的替代方案是將機密資訊儲存在安全的機密資訊管理員中（例如 AWS KMS、 HashiCorp Vault、 Pangea 等），並在您的應用程式啟動時（例如 Docker 容器、EC2）請求它們。

範例

此規則的不正確程式碼範例

const AWS_ACCESS_KEY_ID = "AKIA1234X678C123B567";
const OPENAI_API_KEY = "sk_test_1234567890";

此規則的正確程式碼範例

const AWS_ACCESS_KEY_ID = process.env.AWS_ACCESS_KEY_ID;
const OPENAI_API_KEY = await getSecret("open-ai-api-key");

參考資料

• 規則來源