ให้ AI เขียนทั้งระบบ กับเขียนทีละส่วนแล้วตรวจเอง ต่างกันตรงไหนเรื่องความปลอดภัยของข้อมูล

ทีมเล็ก ๆ ทีมหนึ่งใช้ AI สร้างระบบเก็บข้อมูลลูกค้าสำหรับแคมเปญโปรโมชัน ทุกอย่างดูทำงานได้ดีตอนทดลอง กรอกฟอร์มได้ ข้อมูลขึ้นใน Dashboard ได้ พวกเขาเปิดให้ใช้งานจริงทันทีเพราะเห็นว่า 'มันรันได้' จนสองสัปดาห์ต่อมามีคนสังเกตว่า API Key ของบริการส่งอีเมลถูกฝังอยู่ในโค้ดฝั่ง Client ที่ใครก็เปิดดูได้จาก Browser DevTools เรื่องนี้ไม่ใช่บั๊กที่ทำให้แอปพัง แต่เป็นช่องโหว่ที่รอวันถูกใช้ในทางที่ผิด

เหตุการณ์แบบนี้ไม่ใช่เรื่องแปลกเมื่อปล่อยให้ AI เขียนโค้ดทั้งระบบรวดเดียวโดยไม่มีจุดตรวจ เพราะ AI ตรวจสอบตัวเองได้แค่ว่า 'โค้ดรันได้ตามที่เขียน' ไม่ใช่ 'โค้ดนี้ปลอดภัยพอจะเปิดให้คนภายนอกใช้งาน' สองเรื่องนี้คนละมิติกันโดยสิ้นเชิง และการเข้าใจผิดว่าเหมือนกันคือจุดเริ่มต้นของปัญหาส่วนใหญ่ที่เจอ

บทความนี้จะเทียบให้เห็นว่าการปล่อยให้ AI เขียนทั้งระบบรวดเดียวกับการแบ่งเขียนทีละส่วนแล้วให้คนตรวจ Diff ก่อนไปต่อ มีความเสี่ยงด้าน Security ต่างกันตรงไหนบ้าง และมีวิธีไหนที่ลดความเสี่ยงได้โดยไม่เสียความเร็วไปทั้งหมด

สองแนวทางที่ทีมส่วนใหญ่เลือกใช้จริง

แนวทางแรกคือปล่อยให้ AI ทำงานยาวต่อเนื่อง อธิบาย Prompt ครั้งเดียวให้ครอบคลุมทั้งระบบ แล้วรอดูผลลัพธ์ตอนจบ วิธีนี้เร็วมากในแง่เวลาที่ใช้เขียนโค้ด เพราะแทบไม่ต้องหยุดรอคนระหว่างทาง แต่ก็หมายความว่าไม่มีใครเห็นการตัดสินใจทีละจุดที่ AI เลือก เช่น จะเก็บ Secret ไว้ที่ไหน จะเปิดสิทธิ์เข้าถึงฐานข้อมูลกว้างแค่ไหน

แนวทางที่สองคือแบ่งงานเป็นส่วนย่อย ให้ AI เขียนทีละชิ้น แล้วให้คนอ่าน Diff ก่อนกดยอมรับให้ไปต่อทุกครั้ง วิธีนี้ช้ากว่าในแง่เวลาที่ใช้ทั้งโครงการ เพราะต้องหยุดรอคนตรวจบ่อย แต่ข้อดีคือปัญหาด้าน Security ถูกจับได้ตั้งแต่จุดที่เกิดขึ้น ไม่ต้องรอให้ระบบเสร็จทั้งหมดแล้วค่อยไล่หา ซึ่งยากกว่ามากเพราะปัญหาอาจกระจายอยู่หลายจุด

ความต่างของสองแนวทางนี้ไม่ใช่แค่เรื่องความเร็ว แต่เป็นเรื่องว่า 'ใครเป็นคนตัดสินใจเรื่อง Security' ถ้าไม่มีคนเข้าไปดูเลย การตัดสินใจทั้งหมดจะเป็นของ AI ที่เลือกจากรูปแบบทั่วไปที่พบบ่อยในข้อมูลที่เรียนรู้มา ไม่ใช่ตามระดับความอ่อนไหวของข้อมูลจริงที่ระบบนั้นเก็บ

จุดที่ Secret และ API Key มักหลุดโดยไม่มีใครรู้ตัว

ปัญหาที่เจอบ่อยที่สุดคือ AI เก็บ Secret เช่น API Key, Database Password หรือ Token ต่าง ๆ ไว้ในไฟล์โค้ดฝั่ง Client โดยตรง เพราะเป็นวิธีที่ 'ทำให้โค้ดรันได้เร็วที่สุด' ในมุมของการแก้ปัญหาทันที แต่ผลคือใครก็ตามที่เปิดดูโค้ดฝั่ง Browser ผ่าน DevTools จะเห็น Secret เหล่านั้นตรง ๆ โดยไม่ต้องแฮกอะไรเลย

อีกรูปแบบที่พบคือ Secret ถูกใส่ไว้ในไฟล์ที่ Commit ขึ้น Repository สาธารณะโดยไม่ตั้งใจ เพราะ AI ไม่ได้รู้โดยอัตโนมัติว่าไฟล์ Environment Variable ควรถูกกันไว้ในรายการที่ไม่ Commit ถ้าคนไม่ได้ตั้งค่านี้ไว้ตั้งแต่ต้น หรือไม่ได้ตรวจก่อน Push โค้ดขึ้น Repository สาธารณะ

วิธีป้องกันที่ทำได้จริงคือกำหนดตั้งแต่ต้น Prompt ว่า Secret ทุกตัวต้องเก็บผ่านตัวแปรสภาพแวดล้อมฝั่ง Server เท่านั้น ห้ามฝังในโค้ดฝั่ง Client และก่อน Deploy ทุกครั้งต้องมีขั้นตอนค้นหาคำที่มีลักษณะเป็น Key หรือ Token ในโค้ดทั้งหมดก่อนปล่อยออกไป ไม่ว่าจะเขียนด้วยมือหรือด้วย AI ก็ตาม

ฐานข้อมูลเปิดกว้างเกินจำเป็น ปัญหาที่มองไม่เห็นจนสาย

อีกจุดที่เจอบ่อยคือการตั้งค่าสิทธิ์การเข้าถึงฐานข้อมูลกว้างเกินความจำเป็น เช่น อนุญาตให้ทุก Request อ่านและเขียนข้อมูลได้โดยไม่ตรวจสิทธิ์ก่อน เพราะเป็นวิธีที่ทำให้ฟีเจอร์ที่ Prompt ขอทำงานได้เร็วที่สุดในตอนทดลอง แต่ไม่มีการจำกัดสิทธิ์ตามบทบาทผู้ใช้จริงตามที่ระบบควรมี

ความเสี่ยงแบบนี้ไม่แสดงอาการอะไรตอนทดลองใช้งานปกติ เพราะทุกคนที่ทดสอบมักมีสิทธิ์เต็มอยู่แล้ว ปัญหาจะโผล่มาก็ต่อเมื่อมีคนพยายามเข้าถึงข้อมูลที่ไม่ควรเห็น เช่น ผู้ใช้ทั่วไปพยายามเรียกดูข้อมูลของผู้ใช้คนอื่นผ่าน API โดยตรง ซึ่งถ้าไม่มีการตรวจสิทธิ์ในระดับ Endpoint ก็มีโอกาสเข้าถึงได้จริง

ทางแก้คือกำหนดกฎการเข้าถึงข้อมูล (Access Rule) ไว้ตั้งแต่ตอนออกแบบ ไม่ใช่ปล่อยให้ AI เดาเอง เช่น ระบุชัดว่าผู้ใช้แต่ละคนดูได้เฉพาะข้อมูลของตัวเอง ยกเว้นบทบาทแอดมิน แล้วให้คนที่เข้าใจโครงสร้างสิทธิ์ทดสอบด้วยการสวมบทบาทผู้ใช้ทั่วไปจริง ๆ ว่าเข้าถึงข้อมูลนอกเหนือสิทธิ์ได้หรือไม่ ก่อนเปิดใช้งานจริง

Endpoint ที่ลืมตรวจสิทธิ์ ช่องโหว่ที่เจอซ้ำที่สุด

เมื่อ AI สร้าง API Endpoint ใหม่เพื่อรองรับฟีเจอร์ตาม Prompt มันมักโฟกัสที่ 'ทำให้ฟีเจอร์นั้นทำงานได้' เป็นอันดับแรก ส่วนการตรวจสิทธิ์ก่อนอนุญาตให้เรียก Endpoint นั้นอาจถูกมองข้ามไปถ้า Prompt ไม่ได้ระบุไว้ชัดเจน โดยเฉพาะ Endpoint ที่ดูเหมือนไม่อ่อนไหว เช่น Endpoint ดึงรายชื่อสินค้า แต่ดันมีพารามิเตอร์ที่ใช้ดึงข้อมูลผู้ใช้แนบมาด้วยโดยไม่รู้ตัว

วิธีตรวจที่ทำได้จริงคือไล่ดูรายการ Endpoint ทั้งหมดที่ระบบมี แล้วถามทีละตัวว่า 'ถ้าคนที่ไม่ได้ Login เรียก Endpoint นี้ตรง ๆ จะเกิดอะไรขึ้น' ถ้าคำตอบคือได้ข้อมูลที่ไม่ควรเห็น นั่นคือจุดที่ต้องเพิ่มการตรวจสิทธิ์ก่อนใช้งานจริง การไล่แบบนี้ทำได้ทั้งด้วยมือสำหรับระบบเล็ก หรือใช้เครื่องมือทดสอบ API อัตโนมัติช่วยยิง Request แบบไม่มีสิทธิ์เข้าไปดูผลลัพธ์

ตารางเทียบความเสี่ยง: ปล่อยเขียนยาว กับ แบ่งตรวจทีละส่วน

สรุปเป็นตารางเพื่อให้เห็นภาพรวมของทั้งสองแนวทางในมิติที่เกี่ยวกับ Security โดยตรง:

ทางสายกลางที่ใช้ได้จริง ไม่เสียความเร็วไปทั้งหมด

ทีมที่ทำงานได้ผลจริงมักไม่เลือกสุดทางใดทางหนึ่ง แต่กำหนด 'จุดตรวจ Security ที่บังคับ' ไว้เฉพาะช่วงสำคัญ เช่น หลังสร้างระบบยืนยันตัวตนเสร็จ หลังเพิ่ม Endpoint ใหม่ที่แตะข้อมูลผู้ใช้ และก่อน Deploy ขึ้นใช้งานจริงทุกครั้ง ส่วนช่วงอื่นที่ความเสี่ยงต่ำกว่า เช่น การปรับ UI หรือข้อความในหน้าจอ ปล่อยให้ AI ทำงานต่อเนื่องได้โดยไม่ต้องหยุดตรวจถี่เท่ากัน

วิธีนี้คล้ายกับแนวทางที่พูดถึงไว้ใน การวางขั้นตอนให้ทีมทำงานร่วมกับ Agent อย่างปลอดภัย ที่เน้นตั้ง Checkpoint ตามจุดสำคัญแทนการตรวจทุกบรรทัดหรือไม่ตรวจเลย เพียงแต่ในเรื่อง Security ต้องเจาะจงกว่านั้นอีกขั้น คือระบุชัดว่า Checkpoint ไหนต้องมีคนที่เข้าใจเรื่องความปลอดภัยเข้าไปดูโดยเฉพาะ ไม่ใช่แค่คนที่ดู UI ผ่านตา

เครื่องมือต่างกัน ความเสี่ยงก็ต่างจุดกันด้วย

เครื่องมือที่รันในเบราว์เซอร์ เช่น Bolt.new มักมีความเสี่ยงเรื่อง Secret หลุดในโค้ดฝั่ง Client สูงกว่า เพราะสภาพแวดล้อมแบบนี้เอื้อให้ทุกอย่างรันอยู่ในที่เดียวโดยไม่มีการแยกฝั่ง Server ชัดเจนตั้งแต่ต้น ถ้าไม่ได้ตั้งค่า Environment Variable ให้ถูกจุด Secret มีโอกาสไปโผล่ในโค้ดที่เบราว์เซอร์โหลดมาแสดงผลได้ง่าย

ส่วนเครื่องมือแบบ Code Editor ที่ทำงานกับโปรเจกต์ในเครื่อง เช่น Cursor เปิดโอกาสให้ตรวจ Diff และใช้เครื่องมือ Git ควบคู่ได้ง่ายกว่า แต่ก็ไม่ได้แปลว่าปลอดภัยขึ้นเองโดยอัตโนมัติ ถ้าคนที่รีวิว Diff ไม่มีความรู้เรื่อง Security เพียงพอ ก็ยังกด Accept ผ่านโค้ดที่มีช่องโหว่ได้เหมือนกัน เครื่องมือช่วยให้ 'มีโอกาสตรวจ' มากขึ้น แต่ไม่ได้ตรวจให้แทนคน

ความเข้าใจผิดเรื่อง Security ที่เจอบ่อยที่สุด

ก่อนปิดท้าย ลองดูความเข้าใจผิดสามแบบที่ทำให้ทีมเจอปัญหา Security ซ้ำ ๆ:

• เข้าใจว่า 'โค้ดรันได้ไม่มี Error' เท่ากับ 'โค้ดปลอดภัยแล้ว' ทั้งที่เป็นคนละเรื่องกันโดยสิ้นเชิง
• เชื่อว่า AI รู้เองว่าข้อมูลไหนอ่อนไหวควรป้องกันเป็นพิเศษ ทั้งที่ AI ตอบตาม Prompt ที่ได้รับเป็นหลัก ถ้าไม่ได้ระบุไว้ก็มีโอกาสมองข้าม
• รอให้ระบบเสร็จสมบูรณ์ทั้งหมดก่อนค่อยตรวจ Security ทีเดียว แทนที่จะตรวจเป็นระยะตามจุดที่แตะข้อมูลอ่อนไหว ทำให้เมื่อเจอปัญหาต้องแก้หลายจุดพร้อมกันในเวลาจำกัด

สรุป

ความเสี่ยงด้าน Security ของ Vibe Coding ไม่ได้อยู่ที่ตัวเครื่องมือเก่งหรือไม่เก่ง แต่อยู่ที่ว่ามีคนเข้าไปตัดสินใจเรื่องความปลอดภัยระหว่างทางมากแค่ไหน ปล่อยให้ AI เขียนทั้งระบบรวดเดียวโดยไม่มีจุดตรวจคือความเสี่ยงที่สูงที่สุด ในขณะที่การตรวจทุกบรรทัดตลอดเวลาก็ทำให้เสียข้อได้เปรียบเรื่องความเร็วไปเกือบหมด

ทางที่ใช้ได้จริงคือกำหนดจุดตรวจ Security ที่บังคับไว้เฉพาะช่วงสำคัญ อย่าง Secret, สิทธิ์การเข้าถึงข้อมูล และ Endpoint ที่แตะข้อมูลผู้ใช้ แล้วปล่อยให้ AI ทำงานเร็วในส่วนที่เหลือ วิธีนี้รักษาทั้งความเร็วและความปลอดภัยไว้พร้อมกันได้ดีกว่าเลือกสุดทางใดทางหนึ่ง

• ปล่อยให้ AI เขียนทั้งระบบรวดเดียวเสี่ยงเรื่อง Secret หลุดและสิทธิ์เข้าถึงข้อมูลกว้างเกินจำเป็นมากกว่า
• แบ่งเขียนทีละส่วนแล้วตรวจ Diff ช้ากว่าแต่จับปัญหา Security ได้เร็วกว่าตั้งแต่จุดที่เกิดขึ้น
• จุดที่ต้องตรวจเสมอคือ Secret ในโค้ดฝั่ง Client สิทธิ์การเข้าถึงฐานข้อมูล และ Endpoint ที่ไม่ตรวจสิทธิ์ก่อนใช้งาน
• ทางสายกลางคือกำหนดจุดตรวจ Security บังคับเฉพาะช่วงสำคัญ ไม่ต้องตรวจทุกบรรทัดหรือปล่อยผ่านทั้งหมด

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