// docs / baas security / umbrella scanner

BaaS misconfiguration scanner: tìm đường dẫn dữ liệu công khai trước khi người dùng tìm thấy

Name: BaaS misconfiguration scanner: tìm đường dẫn dữ liệu công khai trước khi người dùng tìm thấy
Brand: FixVibe
Author: FixVibe

Các nhà cung cấp Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — đều thất bại bảo mật theo cùng hình dạng: nền tảng phát hành các mặc định hợp lý, developer (hoặc công cụ AI lập trình) chọn lối tắt, và một đường dẫn công khai mở ra giữa một kẻ tấn công chưa xác thực và dữ liệu khách hàng. Một BaaS misconfiguration scanner là công cụ duy nhất thăm dò đường dẫn đó từ bên ngoài theo cách mà kẻ tấn công sẽ làm. Bài viết này lập bản đồ năm lớp cấu hình sai lặp lại, giải thích cách lượt quét tổng hợp BaaS của FixVibe hoạt động, so sánh bốn nhà cung cấp lớn và đối chiếu scanner hiểu BaaS với các công cụ DAST chung.

Vì sao các cấu hình sai BaaS có hình dạng lặp lại

Mọi nền tảng BaaS đều theo cùng kiến trúc: một backend được quản lý với một SDK client mỏng nói chuyện với nó từ trình duyệt. Client phía trình duyệt cần một credential — một anon key, một publishable key, một Firebase project ID — để tự nhận diện với backend. Credential đó công khai có chủ ý; sự an toàn của kiến trúc dựa vào việc các kiểm soát truy cập cấp nền tảng (RLS, rules, allowlist) làm đúng việc của chúng.

Các công cụ AI lập trình xây dựng trên kiến trúc này mà không tiếp thu lớp kiểm soát nền tảng. Chúng kết nối SDK client đúng cách, chấp nhận rules mặc định cho phép của nền tảng (tồn tại để thân thiện với tutorial) và triển khai. Hình dạng lặp lại là: credential công khai + rule mặc định cho phép + thiếu override = phơi nhiễm dữ liệu. Năm lớp cấu hình sai bên dưới đều là biến thể của hình dạng này.

Năm lớp cấu hình sai lặp lại

Chúng xuất hiện trên mọi nhà cung cấp BaaS. Một lượt quét đầy đủ bao gồm cả năm đối với mọi nhà cung cấp đang được sử dụng:

Lớp 1: Sai key trong bundle trình duyệt

Trình duyệt gửi secret/admin key (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) thay vì tương đương công khai/anon. Trình duyệt trở thành một client admin không bị ràng buộc. Được phủ bởi check bundle-secrets của FixVibe.

Lớp 2: Lớp kiểm soát truy cập bị tắt hoặc cho phép

RLS bị tắt, rules Firebase là if true, danh sách callback Auth0 dùng ký tự đại diện. Credential trong trình duyệt là đúng — nhưng ranh giới cấp nền tảng được dự kiến hạn chế nó không làm tròn nhiệm vụ.

Lớp 3: Đọc ẩn danh các tài nguyên nhạy cảm

Các collection Firestore có thể đọc ẩn danh, các bucket storage Supabase có thể liệt kê ẩn danh, API quản lý Auth0 truy cập được ẩn danh. Lượt quét hỏi: "không có credential, tôi có thể đọc gì?"

Lớp 4: Artefact chế độ thử nghiệm trong production

Test key (pk_test_*, sb_test_*) trong một deploy production; ứng dụng Firebase dev-mode có thể truy cập từ tên miền live; ứng dụng Auth0 test-tenant với cài đặt yếu hơn production. Lượt quét so sánh các key runtime với các tiền tố production mong đợi.

Lớp 5: Thiếu xác minh chữ ký webhook

Webhook Clerk, webhook Stripe, webhook Supabase đều ký payload của họ. Một handler không xác minh chữ ký là một primitive ghi cơ sở dữ liệu cho bất kỳ kẻ tấn công nào đoán được URL. Được phát hiện qua hình dạng phản hồi — một yêu cầu chưa ký nhận 200 có nghĩa là xác minh bị bỏ qua.

Cách lượt quét tổng hợp BaaS của FixVibe hoạt động

Phase BaaS của FixVibe chạy ba giai đoạn, mỗi giai đoạn tạo ra các phát hiện riêng biệt:

<strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
Giai đoạn 2 — thăm dò theo nhà cung cấp. Với mỗi nhà cung cấp được phát hiện, scanner chạy check theo nhà cung cấp: baas.supabase-rls thăm dò PostgREST; baas.firebase-rules thăm dò Firestore + RTDB + Storage; baas.clerk-auth0 xác thực tiền tố của các key trong bundle; check bundle-secrets xác thực không có credential cấp dịch vụ nào bị rò rỉ. Mỗi thăm dò chạy độc lập — một phát hiện Supabase không chặn lượt quét Firebase.
Giai đoạn 3 — tương quan chéo nhà cung cấp. Scanner đối chiếu các phát hiện. Một service-role key Supabase bị rò rỉ cùng với thiếu RLS nghiêm trọng hơn từng phát hiện riêng — báo cáo làm nổi điều này. Nhiều nhà cung cấp danh tính (Clerk + Auth0 + auth tùy chỉnh) trong cùng ứng dụng là một phát hiện cấu trúc được đánh dấu để xem xét.

Mọi thăm dò đều thụ động: tối đa một thao tác đọc ẩn danh trên mỗi tài nguyên, với hình dạng phản hồi được ghi lại nhưng nội dung dòng không bao giờ được phân trang hoặc lưu trữ. Thăm dò ghi và sửa đổi được kiểm soát phía sau xác minh quyền sở hữu tên miền — chúng không bao giờ chạy đối với mục tiêu chưa xác minh.

Những gì scanner tìm thấy theo nhà cung cấp

Mỗi nhà cung cấp BaaS có một bề mặt khác và một chiến lược quét khác. Đây là những gì được bao phủ:

Supabase: thiếu RLS trên bảng, bucket storage có thể liệt kê ẩn danh, JWT service_role bị rò rỉ hoặc key sb_secret_* trong bundle, schema bị phơi nhiễm qua liệt kê OpenAPI ẩn danh. Xem Supabase RLS scanner và Danh sách kiểm tra storage.
Firebase: rules if true trên Firestore, Realtime Database và Cloud Storage; bucket Storage có thể liệt kê ẩn danh; thiếu thực thi App Check. Xem Firebase rules scanner và Giải thích rule if-true.
Clerk: secret key sk_* trong bundle, pk_test_* trong production, thiếu xác minh chữ ký webhook, origin được phép ký tự đại diện. Xem Danh sách kiểm tra Clerk.
Auth0: client secret trong bundle, grant Implicit được bật, URL callback / logout ký tự đại diện, thiếu PKCE trên SPA. Xem Danh sách kiểm tra Auth0.

So sánh BaaS scanner với các công cụ DAST và SAST chung

Một scanner hiểu BaaS làm công việc cụ thể mà các công cụ khác không làm. So sánh:

Khía cạnh	FixVibe (DAST hiểu BaaS)	DAST chung (Burp / ZAP)	SAST / SCA (Snyk / Semgrep)
Bao phủ BaaS	Check native cho Supabase, Firebase, Clerk, Auth0, Appwrite	Crawl web chung; không có thăm dò theo nhà cung cấp	Phân tích tĩnh chỉ repo; không xác thực production
Thời gian thiết lập	URL → chạy → kết quả trong 60 giây	Hàng giờ: cấu hình spider, auth, phạm vi	Cả ngày: tích hợp vào CI repo
Nó chứng minh được gì	Phơi nhiễm production-runtime với bằng chứng cấp HTTP	Lỗ hổng web-app (XSS, SQLi); BaaS qua cấu hình thủ công	Mẫu code có thể triển khai hoặc không
Kiểm tra bundle JavaScript	Giải mã JWT, khớp tiền tố secret, duyệt các chunk	Hạn chế — chỉ grep dựa trên chuỗi	Có, nhưng chỉ phía repo, không phải đã triển khai
Quét liên tục	Hàng tháng / theo deploy qua API + MCP	Thủ công; tự cấu hình lịch	Mỗi commit (tốt cho code, mù với runtime)
Giá cho solo / nhóm nhỏ	Gói miễn phí; trả phí từ $19/tháng	Burp Pro $499/năm; ZAP miễn phí nhưng dương tính giả cao	Snyk miễn phí / Semgrep miễn phí; gói trả phí từ $25/dev

Phạm vi trung thực: scanner này không thay thế gì

Một scanner DAST hiểu BaaS là một công cụ tập trung, không phải một chương trình bảo mật toàn diện. Nó không:

Thay thế SAST hoặc SCA. Phân tích tĩnh tìm các CVE dependency (Snyk, Semgrep) và lỗ hổng cấp code (SonarQube) mà một scanner DAST không thể. Chạy cả hai.
Thay thế penetration testing thủ công. Một pentester người tìm các lỗ hổng logic kinh doanh, các trường hợp biên ủy quyền và các lỗ hổng chuỗi mà không scanner nào có thể. Hãy thuê pentester trước một lần ra mắt lớn hoặc kiểm toán tuân thủ.
Kiểm toán code hoặc repo của bạn về secret trong lịch sử git. Check bundle-secrets bao phủ những gì hiện đang được triển khai, không phải những gì đã commit trong lịch sử. Dùng git-secrets hoặc gitleaks để vệ sinh repo.
Bao phủ các dịch vụ backend không phải BaaS. Nếu ứng dụng của bạn dùng backend tùy chỉnh (Express, Rails, Django, FastAPI), FixVibe quét bề mặt HTTP của nó nhưng không thăm dò cơ sở dữ liệu hoặc cơ sở hạ tầng phía sau. Đó là lãnh địa DAST + SAST chung.

Câu hỏi thường gặp

Lượt quét tổng hợp có hoạt động nếu ứng dụng dùng hai nhà cung cấp BaaS (ví dụ: Supabase + Clerk) không?

Có — fingerprint nhà cung cấp và thăm dò theo nhà cung cấp đều độc lập. Scanner phát hiện cả hai, chạy cả hai bộ check và báo cáo các tương quan chéo nhà cung cấp (ví dụ: một JWT template Supabase từ Clerk gửi email như một claim cùng với thiếu RLS).

Điều này khác với việc chạy Burp Suite Pro trên ứng dụng của tôi như thế nào?

Burp là một bàn làm việc DAST chung. Theo mặc định, Burp không biết PostgREST, Firestore hay đường dẫn callback Auth0 là gì — bạn phải cấu hình phạm vi thủ công, viết extension và diễn giải phản hồi. FixVibe ship với các thăm dò BaaS tích hợp sẵn và định dạng bằng chứng theo hình dạng BaaS. Burp thắng về bao phủ web-app chung (XSS, SQLi, logic kinh doanh); FixVibe thắng về các phát hiện đặc thù BaaS.

Còn App Check (Firebase) hoặc xác thực (Apple / Google) thì sao?

App Check làm cho các lượt quét bên ngoài cơ hội trả về 403 trên mọi thăm dò — kết quả đúng cho một bot độc hại. Một lượt quét FixVibe từ một client chưa xác thực hành xử theo cùng cách. Nếu bạn có App Check được bật và FixVibe vẫn báo cáo phát hiện, có nghĩa là rules của bạn cũng mở đối với các client đã xác thực, đó là rủi ro thực sự. App Check + rules đúng là mẫu phòng thủ nhiều lớp.

Scanner có thể xác minh bản sửa của tôi không?

Có — chạy lại sau khi áp dụng bản sửa. ID check (ví dụ: baas.supabase-rls) ổn định trên các lần chạy, vì vậy bạn có thể diff các phát hiện: một phát hiện open trong lần chạy 1 và vắng mặt trong lần chạy 2 là bằng chứng rằng bản sửa đã đến.

Các bước tiếp theo

Chạy một lượt quét FixVibe miễn phí với URL production của bạn — các check phase BaaS có trên mọi gói, bao gồm cả gói miễn phí. Để đi sâu theo nhà cung cấp, các bài viết riêng trong phần này bao phủ chi tiết mỗi nhà cung cấp: Supabase RLS, Phơi nhiễm service-key Supabase, Storage Supabase, Rules Firebase, Firebase if-true, Clerk, và Auth0.