// docs / baas security / auth0 hardening

Auth0 安全清單:22 項

Auth0 是一個介面巨大的身分即服務平台 — 應用程式、API (資源伺服器)、租戶、Actions、Rules (舊版)、連線與授權。其中任一項設定錯誤都是驗證繞過。本清單是涵蓋應用程式、回呼 / 登出允許清單、權杖與刷新輪換、自訂動作、RBAC、異常偵測,以及持續監控的 22 項稽核。每項都可在 Auth0 儀表板中於 10 分鐘內驗證。

關於 Clerk 上的對應清單,請參閱 Clerk 安全清單。關於身分層設定錯誤為何是 AI 工具盲點的背景,請參閱 AI 編碼工具為何留下安全漏洞。

應用程式類型與授權類型

應用程式類型與啟用的授權類型是 Auth0 中影響最大的設定。設錯會打開沒有任何前端程式碼能關閉的攻擊類別。

對僅瀏覽器應用程式使用 Application Type = Single Page Application,對伺服器渲染應用程式使用 Regular Web Application。錯誤的類型允許錯誤的授權類型 — 例如啟用 SPA 授權的 Regular Web App 會啟用無 PKCE 的 Implicit 流程,後者會透過 URL 片段洩漏權杖。
在每個應用程式上停用 Implicit 授權類型。儀表板 → Application → Advanced Settings → Grant Types → 取消勾選 Implicit。Implicit 流程會在 URL 片段中傳回權杖,而 URL 片段會被記錄在瀏覽器歷史與分析中。改用帶 PKCE 的 Authorization Code。
除非有文件化需求,否則停用 Password 授權。Resource Owner Password Credentials (ROPC) 授權要求你自己處理使用者密碼 — 這幾乎抵銷了你購買 Auth0 的大部分理由。除非整合舊系統,否則停用它。
在每個公開用戶端上啟用帶 PKCE 的 Authorization Code。儀表板 → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256,OIDC Conformant = 已啟用。PKCE 對行動應用程式與 SPA 是必要的,用以防止程式碼攔截。

回呼與登出 URL 允許清單

OAuth 回呼路徑上的開放轉址是一種權杖竊取原語。Auth0 的允許清單是你唯一的防禦。

將 Allowed Callback URLs 設為你確切的生產回呼路徑 — 不使用萬用字元。 https://yourapp.com/callback,不是 https://yourapp.com/*。萬用字元回呼會讓攻擊者把權杖轉址到你網域上的任意子路徑。
將 Allowed Logout URLs 設為有限的清單。同樣原則:僅明確 URL。開放的登出轉址會讓攻擊者製作看起來像你登出後狀態的釣魚頁面。
將 Allowed Web Origins 設為僅你的生產來源。用於靜默驗證 (透過隱藏 iframe 進行權杖更新)。萬用字元來源會讓攻擊者頁面能對你的租戶執行靜默驗證。
為 API 端點 (而非應用程式) 設定 Allowed CORS origins。Tenant Settings → Advanced → Allowed CORS origins。預設是空白 (受限);只新增你能控制的明確來源。

權杖與刷新輪換

權杖壽命、刷新輪換與簽章演算法決定了任何權杖洩漏的影響半徑。

啟用 Refresh Token Rotation。Application → Refresh Token Settings → Rotation。每次刷新都會發行新的刷新權杖並使舊的失效。結合絕對過期,能遏止權杖竊取。
將 Refresh Token Reuse Interval 設為 0 (或你的重放容忍度允許的最低值)。重用間隔讓權杖能在相同視窗內使用兩次 — 除非你有特定理由保留它,否則關閉它。
將 Absolute Refresh Token Expiry 設為 14-30 天,而非無限。Application → Refresh Token Expiration → Absolute Expiration。Auth0 預設僅使用 Inactivity,這代表閒置工作階段可持續多年。
將 JWT Signature Algorithm 設為 RS256。Application → Advanced → OAuth → JsonWebToken Signature Algorithm。RS256 使用非對稱簽章,因此用戶端無法偽造權杖。對面向用戶端的應用程式,絕不使用 HS256。
對你的 API 接收的每個 JWT 驗證 aud 與 iss 宣告。在伺服器端使用官方 Auth0 SDK — 它會自動驗證這些。手刻的 JWT 解析通常會跳過對象驗證,這就是驗證繞過。

Actions 與自訂程式碼

Auth0 Actions (與舊版 Rules) 會在登入與其他生命週期事件中於伺服器端執行。它們可以存取整個請求上下文。這裡的不安全程式碼就是租戶範圍的漏洞。

絕不要將 event.user 或 event.transaction 作為整個物件記錄。這些包含電子郵件地址、IP 位址與其他 PII。僅使用欄位層級記錄,且只記錄你需要的內容。
對任何 API 金鑰或 webhook URL 使用機密存放區。Actions → Edit → Secrets。絕不要在 action 程式碼中將 API 金鑰內嵌為字串字面值 — 程式碼對租戶上有 Action 編輯權限的任何人都可見。
在把輸入持久化為 user_metadata 或 app_metadata 之前先驗證它們。把 event.body.name 寫入 user.user_metadata.display_name 的自助式 action 就是一個儲存型 XSS 向量,若你的前端在不轉義的情況下渲染該欄位。

RBAC 與資源伺服器

如果你使用 Auth0 RBAC,角色到權限的對應就是你的授權層。設錯則任何已驗證使用者都能命中管理端點。

在 Auth0 儀表板中明確定義資源伺服器 (API),而非即興定義。每個 API 都有識別碼 (audience)、範圍與簽章設定。沒有註冊的 API,所有權杖都會為隱含的「Auth0 Management API」發行 — 對象錯誤。
為每個 API 設定權限,並在程式碼中以 scope 宣告要求它們。不要在應用程式邏輯中檢查角色成員資格;檢查存取權杖中的範圍。範圍是 OAuth 原生的授權機制。
測試沒有所需角色 / 範圍的已驗證使用者無法命中特權端點。以一般使用者登入,嘗試呼叫 POST /api/admin/users/delete。回應必須是 403。

異常偵測與租戶日誌

Auth0 會發出高訊號事件。請設定它們對你的團隊告警,而不只是堆在日誌緩衝區。

啟用攻擊防護:Bot Detection、Brute Force、Suspicious IP Throttling。儀表板 → Security → Attack Protection。每項在免費方案上預設為關閉;對生產請全部開啟。
將租戶日誌串流到 SIEM 或你的應用程式日誌。儀表板 → Monitoring → Streams。Auth0 在大多數方案上保留日誌 30 天;長期保留需要串流到你自己的系統。
對 fcoa (失敗的跨來源驗證) 與 fp (失敗的登入) 激增告警。在短時間視窗內爆發的這些事件就是憑證填充。將其路由到你的待命頻道。

後續步驟

對你的生產 URL 執行 FixVibe 掃描 — baas.clerk-auth0 檢查會標記被包進 JavaScript 的 Auth0 用戶端機密以及其他身分提供者暴露類別。關於 Clerk 上的對應內容,請參閱 Clerk 安全清單。關於跨 BaaS 提供者的總覽,請閱讀 BaaS 設定錯誤掃描器。