BaaS misconfiguration scanner: ค้นหาเส้นทางข้อมูลสาธารณะก่อนผู้ใช้

ทำไมการตั้งค่าผิด BaaS จึงมีรูปร่างที่เกิดซ้ำ

ทุกแพลตฟอร์ม BaaS มี architecture เดียวกัน: backend ที่จัดการพร้อม client SDK บางที่คุยกับมันจากเบราว์เซอร์ client ที่เผชิญหน้ากับเบราว์เซอร์ต้องการ credential บางตัว — anon key, publishable key, Firebase project ID — เพื่อระบุตัวเองต่อ backend credential นั้นเป็นสาธารณะโดยตั้งใจ; ความปลอดภัยของ architecture พึ่งพาการควบคุมการเข้าถึงระดับแพลตฟอร์ม (RLS, rule, allowlist) ทำงานของมัน

เครื่องมือ AI Coding สร้างบน architecture นี้โดยไม่ internalize ชั้นการควบคุมแพลตฟอร์ม พวกมันเชื่อมต่อ client SDK อย่างถูกต้อง, ยอมรับ rule permissive ค่าเริ่มต้นของแพลตฟอร์ม (ซึ่งมีอยู่เพื่อความเป็นมิตรกับ tutorial) และ ship รูปร่างที่เกิดซ้ำคือ: credential สาธารณะ + rule ค่าเริ่มต้น permissive + การ override ที่ขาดหายไป = การเปิดเผยข้อมูล ห้า class การตั้งค่าผิดด้านล่างเป็นรูปแบบทั้งหมดของรูปร่างนี้

ห้า class การตั้งค่าผิดที่เกิดซ้ำ

สิ่งเหล่านี้ปรากฏใน BaaS provider ทุกตัว การสแกนที่สมบูรณ์ครอบคลุมทั้งห้ากับทุก provider ที่ใช้:

Class 1: key ผิดใน bundle ของเบราว์เซอร์

เบราว์เซอร์ส่ง secret/admin key (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) แทน public/anon ที่เทียบเท่า เบราว์เซอร์กลายเป็น admin client ที่ไม่มีข้อจำกัด ครอบคลุมโดย bundle-secrets check ของ FixVibe

Class 2: ชั้นการควบคุมการเข้าถึงปิดอยู่หรือ permissive

RLS ปิดอยู่, Firebase rule เป็น if true, รายการ callback ของ Auth0 มี wildcard credential ในเบราว์เซอร์เป็นตัวที่ถูกต้อง — แต่ขอบเขตระดับแพลตฟอร์มที่ตั้งใจจะจำกัดมันไม่ทำงาน

Class 3: การอ่านแบบ anonymous ของทรัพยากรที่ละเอียดอ่อน

collection Firestore ที่ anon อ่านได้, Supabase storage bucket ที่ anon list ได้, Auth0 management API ที่ anon เข้าถึงได้ scan ถามว่า: "โดยไม่มี credential ฉันสามารถอ่านอะไรได้บ้าง?"

Class 4: สิ่งประดิษฐ์ test-mode ใน production

key ทดสอบ (pk_test_*, sb_test_*) ใน production deploy; แอป Firebase dev-mode เข้าถึงได้จากโดเมน live; application Auth0 test-tenant ที่มีการตั้งค่าอ่อนกว่า production scan เปรียบเทียบ runtime key กับ prefix production ที่คาดหวัง

Class 5: การตรวจสอบ signature ของ webhook ขาดหายไป

Clerk webhook, Stripe webhook, Supabase webhook ทั้งหมดเซ็น payload ของพวกมัน handler ที่ไม่ตรวจสอบ signature เป็น primitive การเขียนฐานข้อมูลสำหรับผู้โจมตีที่เดา URL ได้ ตรวจจับผ่านรูปร่าง response — request ที่ไม่ได้เซ็นที่ได้ 200 หมายความว่าการตรวจสอบถูกข้าม

FixVibe umbrella BaaS scan ทำงานอย่างไร

BaaS phase ของ FixVibe ทำงานในสามขั้นตอน แต่ละขั้นผลิต finding ที่แตกต่างกัน:

1. <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.
2. ขั้นที่ 2 — probe เฉพาะ provider สำหรับแต่ละ provider ที่ตรวจพบ สแกนเนอร์รัน check เฉพาะ provider: baas.supabase-rls probe PostgREST; baas.firebase-rules probe Firestore + RTDB + Storage; baas.clerk-auth0 validate prefix ของ key ที่ bundle; bundle-secrets check validate ว่าไม่มี credential ระดับ service รั่วไหล แต่ละ probe ทำงานอิสระ — finding Supabase ไม่บล็อก Firebase scan
3. ขั้นที่ 3 — correlation ข้าม provider สแกนเนอร์อ้างอิงข้าม finding Supabase service-role key ที่รั่วไหลร่วมกับ RLS ที่ขาดหายไปรุนแรงกว่า finding ใด finding หนึ่งเพียงอย่างเดียว — รายงานนำเสนอสิ่งนี้ identity provider หลายตัว (Clerk + Auth0 + custom auth) ในแอปเดียวกันคือ finding เชิงโครงสร้างที่ flag ไว้สำหรับการรีวิว

ทุก probe เป็น passive: อ่าน anonymous มากที่สุดหนึ่งครั้งต่อทรัพยากร โดยรูปร่าง response ถูกบันทึกแต่เนื้อหา row ไม่เคยถูก paginate หรือเก็บ Write และ modify probe ถูกจำกัดให้อยู่หลังการยืนยันสิทธิ์ความเป็นเจ้าของโดเมน — พวกมันไม่เคยทำกับเป้าหมายที่ยังไม่ได้ยืนยัน

สแกนเนอร์พบอะไรต่อ provider

แต่ละ BaaS provider มีพื้นผิวที่แตกต่างและกลยุทธ์การสแกนที่แตกต่าง นี่คือสิ่งที่ครอบคลุม:

• Supabase: RLS ที่ขาดบนตาราง, storage bucket ที่ anon list ได้, service_role JWT หรือ sb_secret_* key ที่รั่วไหลใน bundle, schema ที่เปิดเผยผ่านรายการ OpenAPI แบบ anonymous โปรดดู Supabase RLS scanner และ Storage checklist
• Firebase: rule if true บน Firestore, Realtime Database และ Cloud Storage; storage bucket ที่ anon list ได้; การบังคับใช้ App Check ที่ขาดหายไป โปรดดู Firebase rules scanner และ คำอธิบาย if-true rule
• Clerk: secret key sk_* ที่ bundle, pk_test_* ใน production, การตรวจสอบ signature ของ webhook ที่ขาดหายไป, allowed origin ที่มี wildcard โปรดดู Clerk checklist
• Auth0: client secret ที่ bundle, Implicit grant ที่เปิดใช้, callback / logout URL ที่มี wildcard, PKCE ที่ขาดบน SPA โปรดดู Auth0 checklist

BaaS scanner เปรียบเทียบกับเครื่องมือ DAST และ SAST ทั่วไปอย่างไร

BaaS-aware scanner ทำงานเฉพาะที่เครื่องมืออื่นไม่ทำ การเปรียบเทียบ:

ขอบเขตที่ตรงไปตรงมา: สิ่งที่สแกนเนอร์นี้ไม่ทดแทน

BaaS-aware DAST scanner เป็นเครื่องมือที่เจาะจง ไม่ใช่โปรแกรมความปลอดภัยเต็มรูปแบบ มันไม่:

• ทดแทน SAST หรือ SCA การวิเคราะห์ static ค้นหา CVE ของ dependency (Snyk, Semgrep) และช่องโหว่ระดับโค้ด (SonarQube) ที่ DAST scanner ทำไม่ได้ รันทั้งสอง
• ทดแทนการทดสอบการเจาะระบบโดยมนุษย์ Pentester ที่เป็นมนุษย์ค้นหาช่องโหว่ business-logic, edge case การอนุญาต และช่องโหว่ที่เชื่อมโยงกันที่ไม่มีสแกนเนอร์ใดสามารถทำได้ จ้าง pentester ก่อนการเปิดตัวใหญ่หรือ audit การปฏิบัติตามข้อกำหนด
• Audit โค้ดหรือ repo ของคุณสำหรับ secret ใน git history bundle-secrets check ครอบคลุมสิ่งที่ deploy ในปัจจุบัน ไม่ใช่สิ่งที่ commit ในอดีต ใช้ git-secrets หรือ gitleaks สำหรับ repo hygiene
• ครอบคลุม service backend ที่ไม่ใช่ BaaS หากแอปของคุณใช้ backend กำหนดเอง (Express, Rails, Django, FastAPI) FixVibe สแกนพื้นผิว HTTP แต่ไม่ probe ฐานข้อมูลหรือ infrastructure เบื้องหลัง นั่นคืออาณาเขตของ DAST ทั่วไป + SAST

คำถามที่พบบ่อย

ขั้นตอนถัดไป

รัน FixVibe scan ฟรีกับ URL production ของคุณ — BaaS-phase check มาในทุกแพ็กเกจ รวมถึงระดับฟรี สำหรับการเจาะลึกเฉพาะ provider บทความเดี่ยวในส่วนนี้ครอบคลุมแต่ละ provider ในรายละเอียด: Supabase RLS, การเปิดเผย service-key ของ Supabase, Supabase storage, Firebase rule, Firebase if-true, Clerk และ Auth0