16,326 ฐานข้อมูลบน Supabase เปิดให้ใครก็อ่านได้: ข้อมูลหลุดยังไง และแอปที่สร้างกับ AI ต้องเช็กอะไร
ถ้าคุณเคยสร้างแอปหรือเว็บกับ AI แล้วมันบอกว่า "ต่อฐานข้อมูลให้แล้ว" มีโอกาสสูงที่ฐานข้อมูลนั้นอยู่บน Supabase และงานวิจัยล่าสุดชี้ว่าแอปแบบนี้หลายหมื่นตัวกำลังเปิดข้อมูลลูกค้าให้คนแปลกหน้าอ่านได้ ไม่ใช่เพราะโดนแฮก แต่เพราะไม่มีใครล็อกประตูตั้งแต่แรก
วันที่ 25 กันยายน 2026 บริษัทความปลอดภัยไซเบอร์ UpGuard เผยผลวิจัยที่พวกเขาเรียกว่าการสำรวจเรื่องนี้ที่ใหญ่ที่สุดเท่าที่เคยมี พบ 16,326 ฐานข้อมูล บน Supabase ที่อ่านตารางได้จากอินเทอร์เน็ตโดยตรง TechCrunch รายงานข่าวนี้ในวันเดียวกัน
Supabase คืออะไร และทำไมมันอยู่ในแอปที่ AI สร้าง
แอปแทบทุกตัวต้องมีที่เก็บข้อมูล เช่น รายชื่อลูกค้า คำสั่งซื้อ ข้อความที่ผู้ใช้พิมพ์ ที่เก็บนี้เรียกว่าฐานข้อมูล Supabase คือบริการที่เช่าฐานข้อมูลพร้อมระบบ login ให้คุณแบบสำเร็จรูป ไม่ต้องตั้งเซิร์ฟเวอร์เอง
ความสะดวกนี้ทำให้มันกลายเป็นตัวเลือกยอดนิยมของแอปที่สร้างด้วย AI หรือที่เรียกว่า vibe coding TechCrunch ระบุว่า Supabase ขึ้นไปถึงมูลค่า 10,000 ล้านดอลลาร์เมื่อต้นปีนี้ ส่วนหนึ่งมาจากกระแสนักพัฒนาที่นำแอปแบบนี้ไปวางบนแพลตฟอร์ม
UpGuard เจออะไร
วิธีสำรวจของ UpGuard ตรงไปตรงมา พวกเขาเริ่มจากเว็บราว 300,000 โดเมนที่มีร่องรอยการใช้ Supabase อยู่ในไฟล์ JavaScript ที่เปิดดูได้สาธารณะ แล้วลองขออ่านตารางชื่อ users จากแต่ละเว็บ เพราะเป็นชื่อตารางที่คนตั้งกันบ่อย ผลคือเจอ 16,326 ฐานข้อมูลที่อ่านได้อย่างน้อยบางตาราง
ในกลุ่มนั้น
- มากกว่าครึ่งมีร่องรอยข้อมูลที่ระบุตัวบุคคลได้ เช่น ชื่อ ที่อยู่ เบอร์โทร อีเมล
- ส่วนที่น้อยกว่ามีรหัสผ่านหรือ token สำหรับยืนยันตัวตน
- มีจำนวนน้อยมากที่ดูเหมือนมีข้อมูลบัตรเครดิต
ตัวอย่างที่ UpGuard ยกมามีทั้ง บริการรับจอดรถในสหรัฐฯ ที่ข้อมูลลูกค้ากว่า 100,000 รายหลุด รวมทะเบียนรถ 78,000 คัน บริการที่ปรึกษาย้ายประเทศในแคนาดาที่มี 5,000 บัญชีผู้ใช้ และ 884 บัญชีเก็บรหัสผ่านแบบอ่านออกตรง ๆ ฐานข้อมูลของสถานกงสุลประเทศหนึ่งในแอฟริกาที่ประจำฝรั่งเศส และระบบ SIM farm ในฟิลิปปินส์ที่มีข้อความ SMS รหัส OTP กว่า 100,000 ข้อความ
UpGuard บอกว่าปัญหานี้เกิดทั่วโลก ไม่ได้กระจุกที่ประเทศเดียว ยุโรปทำได้ดีกว่าเพราะกฎหมายคุ้มครองข้อมูลบังคับ ส่วนประเทศกำลังพัฒนามีอัตราข้อมูลหลุดสูงกว่า
ข้อมูลหลุดออกไปได้ยังไง
ตรงนี้คือส่วนที่คุณควรเข้าใจจริง ๆ เพราะมันอธิบายว่าทำไมแอปที่ดูทำงานปกติดีถึงรั่ว
แอปที่ใช้ Supabase แบบทั่วไป หน้าเว็บจะคุยกับฐานข้อมูลโดยตรง และการคุยนั้นต้องใช้กุญแจตัวหนึ่ง เรียกว่า anon key หรือ publishable key กุญแจนี้ถูกฝังไว้ในโค้ดหน้าเว็บ ใครกดดูโค้ดหน้าเว็บก็เห็น และนี่ไม่ใช่ความผิดพลาด Supabase ออกแบบมาให้กุญแจนี้เปิดเผยได้
ที่เปิดเผยได้เพราะมีด่านอีกชั้นหนึ่งรองรับ คือระบบกันสิทธิ์รายแถว เรียกว่า RLS ย่อมาจาก Row Level Security ลองนึกถึงตู้ล็อกเกอร์ในฟิตเนส ทุกคนเข้าห้องล็อกเกอร์ได้ แต่แต่ละตู้เปิดได้เฉพาะเจ้าของ RLS คือกฎที่บอกฐานข้อมูลว่าแต่ละแถวใครเปิดได้ เช่น "ผู้ใช้อ่านได้เฉพาะคำสั่งซื้อของตัวเอง"
ถ้าตารางไหนไม่ได้เปิด RLS ห้องล็อกเกอร์นั้นก็ไม่มีตู้ที่ล็อกเลย ใครถือ anon key ที่เห็นได้จากหน้าเว็บ ก็ขอดึงข้อมูลทั้งตารางได้ เอกสารของ Supabase เองระบุว่าตารางที่ยังไม่เปิด RLS ในส่วนที่เปิดผ่าน API ใครที่มีสิทธิ์ก็ทั้งอ่านและเขียนได้ เปรียบเทียบกับล็อกเกอร์ใช้ได้ถึงตรงนี้ ส่วนที่ต่างคือของจริงร้ายกว่า เพราะคนแปลกหน้าไม่ต้องเดินเข้าห้อง แค่ส่งคำขอผ่านอินเทอร์เน็ตก็หยิบได้ทีละทั้งตาราง
ทำไมแอปที่ AI สร้างถึงเจอบ่อย
Supabase เคยถูกวิจารณ์เรื่องนี้มาก่อน และปรับให้ตารางที่สร้างผ่านหน้าจอ Table Editor ในแดชบอร์ดเปิด RLS ให้เอง แต่ UpGuard ชี้จุดสำคัญว่า ตารางที่สร้างผ่าน API ซึ่งเป็นวิธีที่ AI เขียนโค้ดใช้คุยกับ Supabase จะไม่เปิด RLS ให้อัตโนมัติ
แปลว่าถ้าคุณสั่ง AI ว่า "ทำระบบสมาชิกให้หน่อย" มันอาจสร้างตารางให้ครบ แอปทำงานได้ login ได้ ทุกอย่างดูปกติ แต่ไม่มีอะไรบนหน้าจอบอกคุณเลยว่าตารางยังไม่ได้ล็อก เพราะการไม่ล็อกไม่ทำให้แอปพัง มันแค่ทำให้คนอื่นอ่านได้ด้วย
UpGuard ยังเจอความเข้าใจผิดอีกสองแบบ แบบแรกคือคนคิดว่า anon key เป็นความลับ แล้วรู้สึกปลอดภัยเพราะ "ไม่มีใครรู้กุญแจ" ทั้งที่มันอยู่ในหน้าเว็บให้ทุกคนเห็น แบบที่สองคือเปิด RLS แล้วแต่เขียนกฎหลวมเกินไป เช่น กฎที่อนุญาตให้ทุกคนอ่านทุกแถว ซึ่งให้ผลแทบไม่ต่างกับไม่เปิด
ฝั่ง Supabase ให้ความเห็นผ่าน Bil Harmer ประธานเจ้าหน้าที่ความปลอดภัยสารสนเทศ ว่าบริษัทยังไม่ได้เห็นงานวิจัยนี้ ยืนยันว่าโปรเจกต์ "ปลอดภัยตั้งแต่ค่าเริ่มต้น" และความปลอดภัยเป็นความรับผิดชอบร่วมกัน บริษัทให้ค่าเริ่มต้นและเครื่องมือที่ปลอดภัย ส่วนลูกค้าเป็นคนคุมว่าจะตั้งค่าโปรเจกต์ของตัวเองอย่างไร
ถ้าแอปของคุณใช้ Supabase เช็กแบบนี้
ไม่ต้องเป็นโปรแกรมเมอร์ก็ทำได้ ใช้เวลาไม่กี่นาที
- เปิด Security Advisor เข้าแดชบอร์ดของโปรเจกต์บน Supabase ไปที่หน้า Advisors ส่วน Security มันจะฟ้องรายการชื่อ
rls_disabled_in_publicถ้ามีตารางที่ยังไม่เปิด RLS ถ้าเจอรายการนี้ ให้ถือว่าตารางนั้นเปิดให้คนนอกอ่านและแก้ได้ - สั่ง AI ให้เปิด RLS ทุกตาราง คำสั่งเบื้องหลังคือ SQL บรรทัดเดียวต่อตาราง
alter table public.orders enable row level security;
- ให้ AI เขียนกฎให้ครบ แล้วอ่านกฎเอง พอเปิด RLS แล้วยังไม่มีกฎ เอกสาร Supabase ระบุว่าตารางนั้นจะอ่านผ่าน API ด้วย publishable key ไม่ได้เลย แอปอาจดูเหมือนพัง นี่คือสัญญาณว่าต้องเขียนกฎ ไม่ใช่สัญญาณให้ปิด RLS กลับ บอก AI เป็นภาษาคนว่าใครควรเห็นอะไร เช่น "ลูกค้าเห็นเฉพาะคำสั่งซื้อของตัวเอง แอดมินเห็นทั้งหมด" แล้วให้มันอธิบายกฎที่เขียนกลับมาเป็นภาษาไทยให้คุณตรวจ
- ทดสอบแบบคนนอก ออกจากระบบ หรือใช้บัญชีทดลองอีกบัญชี แล้วดูว่ายังเห็นข้อมูลของคนอื่นอยู่ไหม
- อย่าเก็บรหัสผ่านเอง ใช้ระบบ login ที่ Supabase มีให้ ไม่ต้องสร้างตารางรหัสผ่านขึ้นมาเอง กรณีบริการในแคนาดาที่รหัสผ่าน 884 บัญชีหลุดแบบอ่านออก คือตัวอย่างว่าถ้าพลาดสองชั้นพร้อมกันจะเสียหายแค่ไหน
ถ้าแอปของคุณเก็บข้อมูลลูกค้าคนไทย อย่าลืมว่าข้อมูลส่วนบุคคลอย่างชื่อ เบอร์โทร และที่อยู่ อยู่ภายใต้ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล การรั่วแบบนี้จึงไม่ใช่แค่เรื่องเทคนิค
บทเรียนที่ใหญ่กว่า Supabase
เรื่องนี้ไม่ได้บอกว่า Supabase ใช้ไม่ได้ หรือ vibe coding อันตรายเกินไป มันบอกว่า AI สร้างของที่ ทำงานได้ ให้คุณเร็วมาก แต่ ทำงานได้ กับ ปลอดภัย เป็นคนละเรื่อง แอปที่ไม่ล็อกข้อมูลทำงานได้สมบูรณ์ทุกปุ่ม ปัญหาจึงไม่โผล่ให้เห็นจนกว่าคนอื่นจะเจอก่อน
ส่วนที่ AI เขียนแล้วคุณต้องหยุดตรวจเองคือส่วนที่พลาดแล้วแก้คืนไม่ได้ ข้อมูลที่หลุดไปแล้วเรียกกลับไม่ได้ ถ้าอยากรู้ว่าส่วนไหนของแอปควรระวังแบบนี้ อ่านต่อได้ที่บท แผนที่เขตอันตราย
ที่มา: UpGuard, "Everything, Everywhere: Systemic Data Exposure in Supabase Apps" (25 กันยายน 2026); TechCrunch, "Some Supabase customers are publicly exposing reams of people's data to the web" (25 กันยายน 2026); เอกสาร Supabase เรื่อง Row Level Security และ Database Advisors