- แอปที่ AI ช่วยเขียนทำงานได้จริง แต่ยังไม่มีใครลองเจาะมันก่อนที่คุณจะเปิดให้ลูกค้าใช้
- จุดรั่วที่พบบ่อยมีห้าจุด เจ้าของกิจการถามทดสอบเองได้โดยไม่ต้องอ่านโค้ด
- ถ้าแอปเก็บชื่อ เบอร์โทร หรือประวัติของลูกค้า ควรผ่านการตรวจทั้งห้าจุดก่อนรับข้อมูลจริง
แอปที่ใช้งานได้ ยังบอกอะไรเรื่องความปลอดภัยไม่ได้
สมมติว่าน้องในทีมใช้เครื่องมือ AI สร้างระบบจองคิวเสร็จในสุดสัปดาห์เดียว คุณลองกดจอง กดยกเลิก เปิดดูรายงาน ทุกอย่างทำงาน การทดลองแบบนี้ตอบได้ข้อเดียวว่าคนที่ใช้ตามปกติจะใช้ได้ไหม ยังไม่มีใครถามว่าคนที่ตั้งใจใช้ผิดวิธีจะทำอะไรกับระบบได้บ้าง
Vibe Code คือการสั่งงานด้วยภาษาคนแล้วให้ AI เขียนโค้ดทั้งหมด คนสั่งมักไม่ได้อ่านโค้ดที่ได้ และเครื่องมือก็ถูกออกแบบมาให้ทำตามคำสั่งจนหน้าจอทำงาน ถ้าคำสั่งไม่ได้พูดถึงสิทธิ์การเข้าถึง การเก็บรหัสลับ หรือการตรวจข้อมูลที่ผู้ใช้กรอก โค้ดที่ได้ก็มักไม่มีสิ่งเหล่านั้น หน้าจอยังสวยและกดได้ทุกปุ่มเหมือนเดิม จึงไม่มีอะไรเตือนว่ามีของขาดไป
บริษัทความปลอดภัยซอฟต์แวร์ Veracode ทดสอบโมเดลภาษามากกว่า 100 ตัวกับงานเขียนโค้ด 80 แบบ และรายงานเมื่อเดือนกรกฎาคม 2025 ว่าโค้ดที่ได้มีช่องโหว่ด้านความปลอดภัยใน 45% ของงาน ทั้งที่โค้ดทำงานได้ตามโจทย์ ในปีเดียวกันมีการเปิดเผยช่องโหว่รหัส CVE-2025-48757 ซึ่งพบว่าแอปมากกว่า 170 แอปที่สร้างบนแพลตฟอร์ม Vibe Code ชื่อ Lovable เปิดให้คนนอกอ่านและแก้ข้อมูลในฐานข้อมูลได้โดยไม่ต้องล็อกอิน เพราะไม่ได้ตั้งกฎสิทธิ์ของข้อมูล
ผู้ให้บริการแพลตฟอร์มโต้แย้งว่าการตั้งกฎสิทธิ์เป็นหน้าที่ของเจ้าของแอปแต่ละราย สำหรับเจ้าของกิจการ ข้อโต้แย้งนี้แปลว่าเมื่อข้อมูลรั่ว คนที่ต้องตอบลูกค้าคือคุณ เครื่องมือที่ใช้สร้างแอปไม่ได้รับผิดชอบด้วย
ห้าจุดที่แอป Vibe Code มักรั่ว
นึกถึงร้านที่เพิ่งตกแต่งเสร็จ หน้าร้านสวย เครื่องคิดเงินใช้ได้ แต่ยังไม่มีใครเดินดูว่าประตูหลังล็อกหรือเปล่า กุญแจสำรองวางอยู่ที่ไหน และลิ้นชักเก็บเงินใครเปิดได้บ้าง ห้าจุดในตารางนี้คือประตูหลังของแอป แต่ละจุดมีคำถามที่คุณถามคนสร้างได้เลย
| จุดที่ต้องดู | อาการเมื่อรั่ว | คำถามที่เจ้าของกิจการใช้ทดสอบ |
|---|---|---|
| สิทธิ์ดูข้อมูล | ล็อกอินเป็นลูกค้าคนหนึ่ง เปลี่ยนเลขท้ายลิงก์ แล้วเห็นข้อมูลของลูกค้าอีกคน | ถ้าเปลี่ยนเลขท้ายลิงก์ จะเห็นใบจองของคนอื่นไหม ขอลองให้ดูตอนนี้ |
| กุญแจของระบบ | รหัสเชื่อมต่อฐานข้อมูลหรือบริการรับชำระเงินฝังอยู่ในโค้ดหน้าเว็บ ใครเปิดดูก็เห็น | รหัสของบริการที่เราจ่ายเงินใช้อยู่เก็บไว้ที่ไหน และใครเห็นได้บ้าง |
| ฐานข้อมูล | คนนอกส่งคำสั่งเข้าฐานข้อมูลโดยไม่ผ่านแอป แล้วอ่านได้ทั้งตาราง | มีทางเข้าถึงฐานข้อมูลโดยไม่ผ่านหน้าแอปไหม แต่ละตารางมีกฎกั้นอย่างไร |
| ข้อมูลที่ผู้ใช้ส่งเข้ามา | ช่องกรอกรับข้อความอะไรก็ได้ ช่องอัปโหลดรับไฟล์ทุกชนิด | ถ้ามีคนกรอกคำสั่งแปลก ๆ หรืออัปโหลดไฟล์ที่ไม่ใช่รูป ระบบทำอย่างไร |
| ชุดโค้ดสำเร็จรูปและบันทึกการใช้งาน | แอปใช้ชุดโค้ดรุ่นที่มีช่องโหว่ และเมื่อเกิดเหตุไม่มีบันทึกให้ย้อนดู | ถ้าพรุ่งนี้มีคนแจ้งว่าข้อมูลหลุด เราย้อนดูได้ไหมว่าใครเข้ามาทำอะไร เมื่อไร |
จุดแรกพบบ่อยที่สุดและมองเห็นยากที่สุด OWASP ซึ่งเป็นองค์กรไม่แสวงกำไรด้านความปลอดภัยของซอฟต์แวร์ จัดให้การควบคุมสิทธิ์ที่บกพร่องเป็นความเสี่ยงอันดับหนึ่งของเว็บแอปพลิเคชันในรายการ Top 10 ระบบล็อกอิน (Authentication) ตอบว่าผู้ใช้เป็นใคร ส่วนการกำหนดสิทธิ์ (Authorization) ตอบว่าผู้ใช้คนนั้นดูอะไรได้ AI มักสร้างอย่างแรกให้ครบเพราะมันอยู่บนหน้าจอ อย่างหลังต้องเขียนกฎไว้ทุกจุดที่แอปดึงข้อมูล และเมื่อกฎหายไปก็ไม่มีหน้าจอไหนฟ้อง
จุดที่สองกับสามมักมาคู่กัน แอปที่สร้างเร็วมักต่อฐานข้อมูลจากหน้าเว็บโดยตรง รหัสเชื่อมต่อจึงถูกส่งไปอยู่ในเบราว์เซอร์ของผู้ใช้ทุกคน ฐานข้อมูลรุ่นใหม่รองรับการต่อแบบนี้ได้ถ้าตั้งกฎสิทธิ์ระดับแถวข้อมูล (Row-Level Security) ครบทุกตาราง กรณี Lovable ข้างต้นเกิดจากตารางที่ไม่มีกฎนี้
สำหรับทีมพัฒนา · รายการตรวจเชิงเทคนิค
ตรวจ Authorization ฝั่งเซิร์ฟเวอร์ทุก Endpoint ที่รับรหัสอ้างอิงของข้อมูล เปิด Row-Level Security พร้อม Policy ทุกตาราง ย้าย Secret ออกจาก Bundle และประวัติของ Repository ไปไว้ใน Secret Manager ใช้ Parameterized Query กับ Input Validation ทุกช่อง จำกัดชนิดและขนาดไฟล์อัปโหลด ตั้ง Rate Limit ที่หน้าล็อกอิน รัน Dependency Scan และ Secret Scan ใน CI และเก็บ Audit Log ของการอ่านและแก้ไขข้อมูลส่วนบุคคล
กรณีจำลอง
คลินิกกายภาพบำบัดกับลิงก์ใบนัดที่เปลี่ยนเลขได้
คลินิกกายภาพบำบัดสามสาขาให้ผู้จัดการสาขาสร้างระบบจองคิวด้วยเครื่องมือ AI ระบบส่งลิงก์ใบนัดให้คนไข้ทางข้อความ ลิงก์ลงท้ายด้วยเลขลำดับของใบนัด เช่น 1042 คนไข้คนหนึ่งลองเปลี่ยนเลขเป็น 1041 แล้วเห็นชื่อ เบอร์โทร และอาการของคนไข้อีกคน เขาแคปหน้าจอส่งมาที่เพจของคลินิก
คลินิกปิดระบบหนึ่งสัปดาห์และกลับไปจดคิวในสมุด งานแก้ใช้เวลาไม่กี่วัน คือเพิ่มกฎฝั่งเซิร์ฟเวอร์ให้ใบนัดเปิดได้เฉพาะเจ้าของกับพนักงานของสาขานั้น เปลี่ยนเลขลำดับเป็นรหัสสุ่ม และเริ่มเก็บบันทึกการเปิดดู ส่วนที่ตอบไม่ได้คือคำถามว่าก่อนหน้านี้มีใครเปิดใบนัดของคนอื่นไปแล้วกี่ครั้ง เพราะระบบเดิมไม่เคยบันทึก ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหวตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล คลินิกจึงต้องให้ที่ปรึกษากฎหมายประเมินว่าต้องแจ้งเหตุต่อใครบ้าง
ตรวจห้าประตูก่อนรับข้อมูลจริง
- เขียนรายการข้อมูลทุกอย่างที่แอปเก็บ แล้วทำเครื่องหมายรายการที่เป็นข้อมูลส่วนบุคคลหรือเกี่ยวกับเงิน
- สร้างบัญชีทดสอบสองบัญชี ล็อกอินบัญชีแรก แล้วลองเปิดทุกลิงก์ที่ได้จากบัญชีที่สอง
- ให้คนที่อ่านโค้ดเป็นค้นหารหัสลับในโค้ดหน้าเว็บและในประวัติการแก้ไขโค้ด
- ขอดูกฎสิทธิ์ของฐานข้อมูลทีละตาราง ตารางไหนไม่มีกฎให้ถือว่าเปิดอยู่
- จำลองเหตุด้วยคำถามเดียว ถ้าเมื่อวานมีคนดึงข้อมูลออกไป วันนี้เราจะรู้จากอะไร
จดผลของแต่ละข้อพร้อมวันที่ตรวจและชื่อคนตรวจ เก็บไว้เป็นหลักฐานว่าบริษัทได้ตรวจก่อนเปิดใช้ วิธีนี้จับช่องโหว่พื้นฐานได้ แต่ยังแทนการทดสอบเจาะระบบโดยผู้เชี่ยวชาญไม่ได้ แอปที่รับชำระเงินหรือเก็บข้อมูลอ่อนไหวต้องไปต่ออีกขั้น
ต้องตรวจลึกแค่ไหน ขึ้นกับข้อมูลที่แอปถืออยู่
บ้านทุกหลังควรล็อกประตู แต่มีแค่บางหลังที่ต้องติดตู้เซฟ แอปก็เหมือนกัน ระดับการตรวจควรตามมูลค่าและความอ่อนไหวของข้อมูล การทำเกินจำเป็นกับเครื่องมือเล็ก ๆ ก็เป็นการใช้เงินผิดที่
เครื่องมือภายในที่ไม่มีข้อมูลลูกค้า เช่น ตัวคำนวณราคาที่ใช้กันในทีมขาย สร้างด้วย Vibe Code แล้วใช้ได้เลย ขอแค่ตรวจว่าไม่มีรหัสลับของบริษัทฝังอยู่ในโค้ด แอปที่เก็บชื่อ เบอร์โทร หรืออีเมลของลูกค้าควรผ่านห้าประตูครบ และให้วิศวกรที่ไม่ได้เป็นคนสร้างรีวิวเรื่องสิทธิ์กับรหัสลับก่อนเปิด
แอปที่รับเงิน เก็บข้อมูลสุขภาพ ข้อมูลการเงิน หรือสำเนาบัตรประชาชน ต้องการมากกว่านั้น ควรมี Threat Model ตั้งแต่ขั้นออกแบบ คือการไล่ล่วงหน้าว่าใครอาจโจมตีจากทางไหนและจะเสียหายอะไร แล้วจ้างผู้ทดสอบภายนอกทำ Penetration Test ก่อนเปิด และทำซ้ำเมื่อระบบเปลี่ยนใหญ่
ถ้าแอปมี Chatbot ที่อ่านเอกสารภายใน จะมีความเสี่ยงเพิ่มอีกแบบคือ Prompt Injection ผู้ใช้พิมพ์คำสั่งแฝงเพื่อหลอกให้ AI เปิดเผยข้อมูลที่เขาไม่มีสิทธิ์เห็น วิธีกันที่ได้ผลคือจำกัดสิทธิ์ของ AI ให้เท่ากับสิทธิ์ของคนที่กำลังถาม
ยังไม่ควรเปิดรับข้อมูลจริง ถ้าพบข้อใดข้อหนึ่ง
- ไม่มีใครในทีมบอกได้ว่ารหัสลับของระบบเก็บไว้ที่ไหน
- บัญชีทดสอบหนึ่งเปิดข้อมูลของอีกบัญชีได้
- ฐานข้อมูลมีตารางที่ยังไม่มีกฎสิทธิ์
- ระบบไม่เก็บบันทึกว่าใครเปิดดูหรือแก้ข้อมูลลูกค้า
- ระบุชื่อไม่ได้ว่าใครเป็นผู้รับแจ้งเมื่อเกิดเหตุ
เรื่องค่าใช้จ่าย การตรวจและแก้ก่อนเปิดใช้ถูกกว่าการแก้หลังเกิดเหตุ เพราะหลังเกิดเหตุบริษัทจ่ายค่าแก้เท่าเดิม แล้วยังต้องจ่ายค่าหยุดระบบ เวลาของทีมที่ต้องตอบลูกค้า และภาระตามกฎหมาย กฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทยกำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุละเมิดต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เว้นแต่เหตุนั้นไม่มีความเสี่ยงต่อสิทธิของเจ้าของข้อมูล รายละเอียดการปฏิบัติควรถามที่ปรึกษากฎหมายของบริษัท
ใครก็ Vibe Code ได้ แล้วทีมวิศวกรยังจำเป็นตรงไหน
AI ทำตามสิ่งที่ถูกสั่ง และเรื่องความปลอดภัยส่วนใหญ่เป็นเรื่องที่คนสั่งไม่ได้นึกถึง คนที่เคยดูแลระบบจริงตอนถูกโจมตีรู้ว่าต้องถามอะไรก่อนเริ่มเขียน และรู้ว่าต้องลองทำอะไรกับระบบหลังเขียนเสร็จ
ทีมพัฒนาที่ดีในปีนี้ก็ใช้ AI เขียนโค้ดเหมือนคนทั่วไป สิ่งที่ต่างคือขั้นตอนรอบตัวโค้ด มีการออกแบบสิทธิ์ก่อนลงมือ มีวิศวกรอ่านโค้ดที่ AI เขียนก่อนรวมเข้าระบบ มีเครื่องมือสแกนช่องโหว่ที่รันทุกครั้งที่แก้ และมีคนที่มีชื่ออยู่ในเอกสารส่งมอบ ซึ่งเป็นคนที่คุณโทรหาได้เมื่อเกิดเหตุ
ตัวชี้วัดที่เจ้าของกิจการขอดูได้มีไม่กี่ตัว ได้แก่จำนวนช่องโหว่ที่ยังเปิดอยู่แยกตามความรุนแรง จำนวนวันที่ใช้ปิดช่องโหว่ระดับสูง วันที่ตรวจครั้งล่าสุด และผลการซ้อมรับมือเหตุข้อมูลรั่ว ถ้าไม่มีใครตอบตัวเลขเหล่านี้ได้ แปลว่ายังไม่มีใครดูแลเรื่องนี้อยู่
ตรวจและเสริมความปลอดภัยให้แอปที่สร้างเสร็จแล้ว หรือวางไว้ตั้งแต่วันออกแบบ
เจ้าของกิจการและทีม IT ของคุณรู้ดีที่สุดว่าข้อมูลชุดไหนเสียหายไม่ได้ และที่ปรึกษากฎหมายของบริษัทเป็นผู้ชี้ว่ากฎหมายกำหนดอะไรไว้ DNA Maker เริ่มจากการไล่กับคนเหล่านี้ว่าแอปเก็บข้อมูลอะไร ข้อมูลไหลผ่านจุดไหน และใครควรเห็นอะไร แล้วเขียนออกมาเป็นแผนผังการไหลของข้อมูล ตารางสิทธิ์ตามบทบาท และรายการจุดที่ต้องมีคนอนุมัติ
สำหรับแอปที่ Vibe Code มาแล้ว เราทำ Security Review ตามห้าจุดในบทความนี้ ส่งรายงานช่องโหว่เรียงตามความรุนแรง แล้วแก้ร่วมกับทีมเดิมหรือรับไปแก้ให้ สำหรับระบบใหม่ เราออกแบบสิทธิ์ การเก็บรหัสลับ การตรวจข้อมูลขาเข้า และบันทึกการใช้งานไว้ใน Architecture ตั้งแต่ต้น ใช้ AI ช่วยเขียนโค้ดโดยมีวิศวกรรีวิวทุกชิ้น สแกนโค้ดและชุดโค้ดสำเร็จรูปใน Pipeline และเตรียมระบบให้ผู้ทดสอบเจาะระบบภายนอกเข้าตรวจก่อนเปิดจริง ถ้าคุณมีแอปที่กำลังจะเปิดรับข้อมูลลูกค้า นำลิงก์ของแอปกับรายการข้อมูลที่แอปเก็บมาคุยกับวิศวกรของเรา จะได้รู้ว่าจุดไหนต้องแก้ก่อนเปิด
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
คำเหล่านี้จะได้ยินเมื่อคุยเรื่องความปลอดภัยกับทีมพัฒนา คอลัมน์ขวาสุดคือคำถามที่ใช้ตรวจว่ามีคนดูแลเรื่องนั้นอยู่จริง
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| Authentication | การยืนยันว่าผู้ใช้เป็นใครก่อนให้เข้าระบบ เช่น รหัสผ่าน รหัสทางข้อความ หรือการสแกนใบหน้า | คนไข้กรอกเบอร์โทรกับรหัสที่ได้รับทางข้อความเพื่อเปิดใบนัด | ผู้ใช้กลุ่มไหนต้องยืนยันตัวสองชั้น และถ้าลืมรหัสจะกู้บัญชีอย่างไร? |
| Authorization | กฎที่กำหนดว่าผู้ใช้แต่ละคนดูหรือแก้ข้อมูลใดได้ หลังยืนยันตัวแล้ว | คนไข้เปิดได้เฉพาะใบนัดของตัวเอง พนักงานเปิดได้เฉพาะสาขาที่สังกัด | กฎสิทธิ์ถูกตรวจที่เซิร์ฟเวอร์ทุกครั้งที่ดึงข้อมูลหรือเปล่า และใครเป็นคนทดสอบ? |
| Secret Management | วิธีเก็บรหัสลับของระบบ เช่น รหัสฐานข้อมูลและกุญแจของบริการรับชำระเงิน ให้อยู่นอกโค้ดและจำกัดคนที่เห็น | กุญแจของบริการส่งข้อความอยู่ในระบบเก็บรหัสลับ โค้ดหน้าเว็บไม่มีกุญแจนี้ | ถ้ารหัสลับหลุด เราเปลี่ยนรหัสใหม่ได้ภายในกี่นาที และใครเป็นคนทำ? |
| Row-Level Security | กฎในฐานข้อมูลที่กำหนดว่าผู้ใช้แต่ละคนอ่านหรือแก้ได้เฉพาะแถวข้อมูลใด | ตารางใบนัดคืนเฉพาะแถวที่เป็นของคนไข้ที่ล็อกอินอยู่ | มีตารางไหนที่ยังไม่มีกฎนี้ และเพราะอะไร? |
| Threat Model | การไล่ล่วงหน้าว่าใครอาจโจมตีระบบจากทางไหนและจะเสียหายอะไร เพื่อตัดสินใจว่าต้องป้องกันจุดใดก่อน | ทีมไล่ว่าคนไข้ พนักงานที่ลาออก และคนนอก แต่ละกลุ่มเข้าถึงประวัติการรักษาได้ทางไหน | ความเสี่ยงสามอันดับแรกของระบบเราคืออะไร และแต่ละข้อใครรับผิดชอบ? |
| Penetration Test | การจ้างผู้เชี่ยวชาญลองเจาะระบบจริงภายใต้ข้อตกลง เพื่อหาช่องโหว่ก่อนผู้ไม่หวังดี | ผู้ทดสอบภายนอกลองเข้าถึงข้อมูลคนไข้โดยไม่มีบัญชี แล้วส่งรายงานสิ่งที่ทำได้ | ทดสอบครั้งล่าสุดเมื่อไร ครอบคลุมส่วนไหน และช่องโหว่ที่พบปิดครบหรือยัง? |
| Dependency Scan | การตรวจชุดโค้ดสำเร็จรูปที่ระบบหยิบมาใช้ ว่ามีรุ่นที่มีช่องโหว่ซึ่งถูกเปิดเผยแล้วหรือไม่ | เครื่องมือแจ้งว่าชุดโค้ดจัดการไฟล์อัปโหลดมีช่องโหว่ ทีมจึงอัปเดตก่อนขึ้นระบบ | การสแกนนี้รันทุกครั้งที่แก้โค้ดหรือเปล่า และใครรับการแจ้งเตือน? |