FixVibe

// docs / baas security / clerk hardening

Danh sách kiểm tra bảo mật Clerk: 20 mục

Clerk xử lý auth, phiên và tổ chức cho ứng dụng của bạn — có nghĩa là một tích hợp Clerk cấu hình sai là một auth bypass, một vector cố định phiên, hoặc một đường dẫn rò rỉ tổ chức. Danh sách kiểm tra này là một kiểm toán 20 mục trên các key, cấu hình phiên, webhook, tổ chức, JWT template và giám sát liên tục. Các công cụ AI lập trình kết nối Clerk nhanh chóng với các mặc định hợp lý; danh sách này bắt các mục mà chúng bỏ lại.

Để hiểu lý do tại sao các cấu hình sai lớp auth là điểm yếu của công cụ AI, xem Vì sao công cụ AI lập trình để lại lỗ hổng bảo mật. Để xem danh sách kiểm tra song song trên Auth0, xem Danh sách kiểm tra bảo mật Auth0.

Environment key và danh sách trắng origin

Clerk cấp hai key riêng biệt mỗi dự án. Trộn chúng hoặc làm rò rỉ chúng là chế độ thất bại đầu tiên.

  1. Dùng publishable key (pk_live_* trong production, pk_test_* trong dev) trong trình duyệt; dùng secret key (sk_live_* / sk_test_*) chỉ trên server. Publishable key an toàn trong NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret key không bao giờ được mang tiền tố env công khai và không bao giờ xuất hiện trong một client component.
  2. Xác minh ứng dụng production dùng pk_live_*, không phải pk_test_*. Các instance kiểm tra cho phép địa chỉ email chưa xác minh và MFA bị tắt — đưa chế độ kiểm tra vào production là một auth bypass.
  3. Cấu hình các origin được phép trong Clerk Dashboard. Settings → Domains → Allowed origins phải liệt kê tên miền production của bạn chính xác. Danh sách origin trống hoặc với ký tự đại diện cho phép kẻ tấn công tạo các frontend Clerk lừa đảo nói chuyện với backend của bạn.
  4. Xoay vòng secret key khi có người rời đi hoặc khi nghi ngờ rò rỉ. Dashboard → API Keys → Reset. Key cũ bị vô hiệu hóa; triển khai lại mã phía server với giá trị mới trước khi xoay vòng.

Cấu hình phiên

Thời hạn phiên và timeout không hoạt động là sự khác biệt giữa việc phiên bị đánh cắp là sự cố 10 phút và 30 ngày.

  1. Đặt timeout không hoạt động phiên là 30 phút hoặc ít hơn cho ứng dụng SaaS xử lý dữ liệu nhạy cảm. Dashboard → Sessions → Inactivity timeout. Các ứng dụng cấp ngân hàng nên dùng 5-10 phút; SaaS tiêu chuẩn 30-60 phút; ứng dụng tiêu dùng 1-7 ngày. Mặc định là 7 ngày.
  2. Bật thu hồi phiên khi thay đổi mật khẩu, thay đổi email và đăng ký MFA. Dashboard → Sessions → Revoke on. Đây là các sự kiện bảo mật do người dùng khởi xướng; các phiên hiện tại trên các thiết bị khác nên bị kết thúc.
  3. Xác minh phiên phía server trên mọi route được bảo vệ, không chỉ tại lúc đăng nhập. Trong Next.js: const { userId } = await auth(); trong một server component / API route đọc JWT từ cookie và xác thực nó. Đừng bao giờ tin tưởng một kiểm tra chỉ cookie.
  4. Đặt SameSite=Lax (mặc định) hoặc Strict trên cookie phiên. Xác minh trong DevTools → Application → Cookies. SameSite=None là một vector CSRF — đừng bao giờ dùng nó trừ khi bạn đã cấu hình rõ ràng thiết lập auth liên miền.

Xác minh webhook

Webhook Clerk phát trên các sự kiện vòng đời người dùng (created, updated, deleted, session.ended). Chúng là cơ chế đồng bộ hóa cho cơ sở dữ liệu của bạn — và một webhook giả mạo là một primitive ghi cơ sở dữ liệu.

  1. Xác minh chữ ký Svix trên mọi webhook. Webhook Clerk được ký bởi Svix. Dùng new Webhook(secret).verify(body, headers). Từ chối với 401 nếu xác minh thất bại.
  2. Lưu webhook secret trong biến môi trường, không bao giờ trong code. Secret xoay vòng mỗi khi tái tạo trong Dashboard — bản triển khai của bạn phải đọc nó từ env, không phải từ một hằng số.
  3. Idempotency trên mọi handler. Việc gửi webhook có thể lặp lại. Dùng header svix-id làm khóa chính trong một bảng webhook_events để khử trùng lặp. Bao bọc thay đổi trạng thái và lệnh insert idempotency trong cùng một giao dịch.
  4. Trên user.deleted, xóa cứng hoặc ẩn danh PII trong vòng 24 giờ. GDPR / CCPA yêu cầu điều đó. Kiểm toán đường dẫn xóa: bảng nào giữ dữ liệu của người dùng này? Dùng FK ON DELETE CASCADE ở những nơi bạn có thể.

Tổ chức và quyền

Nếu bạn dùng Clerk Organizations, ranh giới tổ chức là sự cô lập tenant của bạn. Mọi truy vấn phía server phải lọc theo nó.

  1. Trên mọi API route, đọc cả userId và orgId từ auth() và lọc truy vấn cơ sở dữ liệu theo cả hai. WHERE org_id = $orgId AND user_id = $userId. Đừng bao giờ tin tưởng một org_id từ body yêu cầu.
  2. <strong>Use Clerk role checks for privileged operations, not boolean checks against the user object.</strong> <code>has({ role: 'org:admin' })</code> reads the role from the verified JWT. A user can spoof a boolean on a stale client object; they cannot spoof a JWT claim.
  3. Kiểm tra cô lập chéo tổ chức với hai tài khoản tổ chức thực. Tạo Org A, điền dữ liệu, đăng nhập vào Org B trong một trình duyệt khác, thử đọc dữ liệu Org A qua API. Phản hồi phải là 403 hoặc 404.

JWT template và tích hợp bên ngoài

JWT template đẩy danh tính Clerk vào Supabase, Firebase và các dịch vụ downstream khác. Template cấu hình sai chia sẻ quá nhiều claim hoặc làm lộ dữ liệu mà bạn không có ý định.

  1. Với mỗi JWT template, liệt kê mọi claim và xác nhận nó cần thiết. Dashboard → JWT Templates. Một template gửi email và phone đến Supabase làm lộ PII cho bất kỳ ai đọc JWT trong trình duyệt.
  2. Đặt thời hạn ngắn trên JWT template dùng cho lời gọi downstream phía client. 60 giây cho yêu cầu API downstream là tiêu chuẩn. Các JWT có thời hạn dài hơn bị đánh cắp và phát lại.
  3. Xác minh claim audience (aud) ở phía nhận. Supabase, Firebase, v.v. nên kiểm tra rằng aud khớp với định danh dịch vụ mong đợi. Không có cái này, một JWT phát hành cho dịch vụ A có thể xác thực với dịch vụ B.

Giám sát vận hành

Auth là nguồn log có tín hiệu cao nhất mà bạn có. Hãy theo dõi nó.

  1. Cảnh báo khi đăng nhập thất bại tăng đột biến theo IP / theo tài khoản. Tỷ lệ thất bại gấp 50× bình thường là một cuộc tấn công credential stuffing. Clerk phát các sự kiện này đến webhook; định tuyến chúng đến SIEM của bạn.
  2. Xem xét hàng quý sự trôi dạt cài đặt phiên và instance. Các mặc định thay đổi khi Clerk cập nhật; "các cấu hình cũ" âm thầm trở nên sai theo thời gian. Diff bản xuất JSON Dashboard so với bản sao tốt biết cuối cùng của bạn.

Các bước tiếp theo

Chạy một lượt quét FixVibe với URL production — check baas.clerk-auth0 đánh dấu các publishable key Clerk, các test key trong production và các secret key trong bundle. Để xem danh sách kiểm tra tương đương trên Auth0, xem Danh sách kiểm tra bảo mật Auth0. Để có cái nhìn tổng quát trên các nhà cung cấp BaaS, đọc BaaS misconfiguration scanner.

// quét bề mặt baas của bạn

Tìm bảng dữ liệu mở trước khi người khác tìm thấy.

Dán vào một URL production. FixVibe sẽ liệt kê các nhà cung cấp BaaS mà ứng dụng của bạn kết nối tới, fingerprint các endpoint công khai của họ và báo cáo những gì một client chưa xác thực có thể đọc hoặc ghi. Miễn phí, không cần cài đặt, không cần thẻ.

  • Gói miễn phí — 3 lượt quét/tháng, không cần thẻ khi đăng ký.
  • Fingerprinting BaaS thụ động — không cần xác minh tên miền.
  • Supabase, Firebase, Clerk, Auth0, Appwrite và nhiều nữa.
  • Prompt sửa lỗi bằng AI trên mỗi phát hiện — dán lại vào Cursor / Claude Code.
Chạy quét BaaS miễn phí →

không cần đăng ký

Danh sách kiểm tra bảo mật Clerk: 20 mục — Docs · FixVibe