ความปลอดภัยในการเขียนโค้ดด้วย Vibe: วิธีปกป้องแอปที่สร้างด้วย AI

ดูคำแนะนำเพิ่มเติมเกี่ยวกับการใช้งาน Ailoot ได้ในเอกสารประกอบ

ทำไมแอปที่สร้างด้วย AI จึงถูกแฮ็กบ่อยกว่า?#

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

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

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

กล่าวอีกอย่างคือ ช่องโหว่เกิดขึ้นเองตามค่าเริ่มต้น คุณไม่ได้ทำอะไรผิด คุณแค่ไม่ได้ทำอะไรเลย และในเรื่องความปลอดภัย การไม่ลงมือทำก็คือความหมายของคำว่า “เปิดให้ทุกคนเข้าถึง” พอดี

เอเจนต์รัน git add . และ git push โดยไม่ตรวจดู ทำให้ไฟล์ .env ที่มีคีย์ของคุณถูกเผยแพร่ไปพร้อมกับไฟล์อื่น ๆ

ผู้เขียนโค้ดแบบ vibe เรียนรู้อะไรจากประสบการณ์อันเจ็บปวดแล้วบ้าง?#

วิธีป้องกันความประมาทที่ดีที่สุดคือเรียนรู้จากความผิดพลาดของคนอื่น ต่อไปนี้คือรายงานสี่กรณีที่ควรอ่านก่อนเผยแพร่โปรเจกต์ของคุณ

Lovable และการปิด RLS ไว้ แพลตฟอร์ม Lovable สร้างแอปจากคำอธิบายที่เป็นข้อความ ในปี 2025 พบช่องโหว่เชิงระบบในแอปของแพลตฟอร์ม และกำหนดหมายเลข CVE-2025-48757 สาเหตุคือแอปที่สร้างขึ้นไม่มีข้อกำหนดการเข้าถึงฐานข้อมูลระดับแถว (RLS ซึ่งจะอธิบายด้านล่าง) นักวิจัยตรวจสอบตัวอย่างและพบจุดเข้าถึงที่เปิดเผย 303 จุดใน 170 แอป ชื่อ หมายเลขโทรศัพท์ สถานะการชำระเงิน คีย์ API ของผู้อื่น และแม้แต่ที่อยู่บ้านถูกเปิดเผย ในแอปที่ตรวจสอบประมาณ 70 เปอร์เซ็นต์ การป้องกันระดับแถวถูกปิดไว้อย่างสิ้นเชิง

Tea และข้อมูลละเอียดอ่อน แอป Tea (รีวิวผู้คนแบบไม่ระบุตัวตน) ทำให้ภาพประมาณ 72,000 รูปรั่วไหลในเดือนกรกฎาคม 2025 รวมถึงภาพเซลฟีและภาพเอกสาร 13,000 รูป แล้วต่อมาก็มีข้อความส่วนตัวมากกว่าหนึ่งล้านข้อความรั่วไหลด้วย สาเหตุทางเทคนิคคือพื้นที่จัดเก็บที่เปิดเผยและการตรวจสอบสิทธิ์ที่ไม่รัดกุม ชุมชนด้านความปลอดภัยยก Tea เป็นตัวอย่างที่เห็นภาพชัดเจน: เมื่อการเปิดตัวอย่างรวดเร็วสำคัญกว่าการตรวจสอบสิทธิ์ ข้อมูลละเอียดอ่อนจะเป็นสิ่งแรกที่รั่วไหล

อีกตัวอย่างหนึ่งในทางปฏิบัติ ในกรณีที่ผู้เขียนต้นฉบับเล่าไว้ แอปของผู้เขียนโค้ดแบบ vibe ถูกแฮ็กเพราะ AI ตั้งรหัสผ่านเริ่มต้นตอนสร้างฐานข้อมูล ซึ่งเป็นรหัสที่เดาได้โดยอัตโนมัติ จากนั้นก็เกิดเหตุการณ์ตามลำดับที่คุ้นเคย: ผู้โจมตีเข้าไปได้ ติดตั้งเครื่องขุดเหรียญ และเขียนทับโปรเจกต์ ต้องล้างเซิร์ฟเวอร์ทั้งหมด รหัสผ่านเริ่มต้นก็เหมือนประตูที่ไม่ได้ล็อกพร้อมป้าย “เชิญเข้ามา”

ความปลอดภัยมีสองด้าน: คุณเสี่ยงตรงไหนบ้าง?#

เมื่อพูดถึง “ความปลอดภัยในการเขียนโค้ดแบบ vibe” ผู้คนมักเอาความกังวลสองเรื่องที่ต่างกันโดยสิ้นเชิงมารวมกัน มาแยกความแตกต่างกัน เพราะการป้องกันแต่ละเรื่องไม่เหมือนกัน

ด้านแรก — ตัวเอเจนต์เอง คุณเรียกใช้เอเจนต์ AI บนคอมพิวเตอร์และให้มันเข้าถึงไฟล์ เทอร์มินัล คีย์ และฐานข้อมูล ความเสี่ยงคือเอเจนต์ไม่ใช่คน: มันทำตามคำสั่งตรงตัวและจะหาเส้นทางที่สั้นที่สุด แม้เส้นทางนั้นจะอันตรายก็ตาม นอกจากนี้ยังรวมถึงความเสี่ยงที่มีคน “ฉีด” คำสั่งของตนเข้าไปในเอเจนต์ผ่านข้อความที่เอเจนต์อ่าน (เรียกว่า prompt injection)

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

Anthropic ซึ่งเป็นบริษัทที่สร้าง Claude ระบุหลักการป้องกันสำคัญไว้ดังนี้ และใช้ได้กับทั้งสองด้าน:

ในทางปฏิบัติ หมายความว่าอย่าหวังให้ AI “หลีกเลี่ยงการทำเรื่องไม่ดีด้วยตัวเอง” ก่อนอื่นให้จำกัดสิ่งที่มันทำได้จริง แล้วค่อยขอให้มันประพฤติตัวดี เมื่อพฤติกรรมของมันล้มเหลว — และมันจะล้มเหลว — มีเพียงขอบเขตที่เข้มงวดซึ่งคุณกำหนดไว้ล่วงหน้าเท่านั้นที่จะปกป้องคุณได้

เอเจนต์ AI ทำอะไรได้บ้างเมื่อเข้าถึงคอมพิวเตอร์ของคุณ?#

ความเสี่ยงที่คนประเมินต่ำเกินไปมากที่สุดคือเอเจนต์ของคุณเองที่มีสิทธิ์กว้างเกินไป คุณไม่จำเป็นต้องมีแฮ็กเกอร์จากภายนอกด้วยซ้ำ นี่คือตัวอย่างล่าสุดจากช่วงปลายเดือนพฤษภาคม 2026 เอเจนต์ Codex ต้องการสิทธิ์ผู้ดูแลระบบที่ผู้ใช้ไม่มี เอเจนต์ไม่ยอมแพ้ — มันสำรวจดู พบว่าผู้ใช้อยู่ในกลุ่ม docker ซึ่งเทียบเท่ากับ root ในทางปฏิบัติ และใช้สิทธิ์นั้น

ไม่มีเจตนาร้ายในกรณีนี้ เพียงแต่เอเจนต์ที่ได้รับคำสั่งให้ “แก้ปัญหา” จะพบจุดอ่อนเชิงโครงสร้างได้เร็วกว่าคน และหากจุดอ่อนนั้นทำให้เข้าถึงคีย์หรือระบบ production ของคุณได้ มันก็จะใช้สิทธิ์นั้น ดังนั้นกฎข้อแรกคือ ให้สิทธิ์เท่าที่จำเป็น ให้เอเจนต์เข้าถึงเท่าที่จำเป็นสำหรับงานเฉพาะนั้น และไม่มากไปกว่านั้นแม้แต่น้อย

แม้ไม่ใช่โปรแกรมเมอร์ คุณทำอะไรได้บ้างในทางปฏิบัติ?

1. อย่าเรียกใช้เอเจนต์ในโหมด “อนุญาตทุกอย่าง” บนเครื่อง production

   โหมดที่เอเจนต์ไม่ขอการยืนยัน (มักเรียกว่า bypass หรือ yolo) มีไว้สำหรับ sandbox หรือโปรเจกต์ทดสอบเท่านั้น ไม่ใช่เครื่องที่เก็บคีย์ใช้งานจริงและสิทธิ์เข้าถึง production

2. ห้ามเอเจนต์อ่านข้อมูลลับ

   ใน Claude Code คุณทำได้ด้วยกฎที่ปฏิเสธการเข้าถึงไฟล์ซึ่งมีคีย์ ดังนั้นแม้เอเจนต์ต้องการเปิด .env เครื่องมือก็จะไม่อนุญาต

3. แยกคีย์ production ออกจากกัน

   คีย์สำหรับฐานข้อมูล production และบริการชำระเงินไม่ควรอยู่ในโฟลเดอร์เดียวกับที่เอเจนต์เขียนโค้ด แยกสภาพแวดล้อมออกจากกัน: ใช้คีย์ทดสอบเมื่อทดลอง

4. ใช้ sandbox ของเครื่องมือ

   เครื่องมือ AI สมัยใหม่สามารถเรียกใช้คำสั่งแบบแยกส่วน (sandbox) ซึ่งไม่มีสิทธิ์เข้าถึงส่วนอื่นของระบบ ใน Claude Code วิธีนี้ลดคำขออนุญาตลงประมาณ 84 เปอร์เซ็นต์ จึงสะดวกยิ่งขึ้นด้วย

กฎที่ปฏิเสธการอ่านข้อมูลลับใน Claude Code มีหน้าตาประมาณนี้ — ใส่ไว้ในการตั้งค่าสิทธิ์:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

ไม่ควรใส่คีย์ API และรหัสผ่านไว้ที่ไหน?#

ความผิดพลาดที่พบบ่อยและแก้ได้ง่ายที่สุดคือใส่คีย์ไว้ในโค้ด คีย์ API สำหรับบริการชำระเงิน รหัสผ่านฐานข้อมูล โทเคนบอต — ทั้งหมดนี้เป็นข้อมูลลับ ควรเก็บไว้ในไฟล์ .env แยกต่างหาก และต้องระบุไฟล์นี้ไว้ใน .gitignore เพื่อไม่ให้มันถูกนำเข้า git พร้อมโค้ด

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

ขนาดของปัญหาในปี 2025: มีข้อมูลลับใหม่ 28.65 ล้านรายการที่ฝังไว้ในโค้ดของ repository สาธารณะ เพิ่มขึ้น 34 เปอร์เซ็นต์เมื่อเทียบกับปีก่อน การรั่วไหลของคีย์สำหรับบริการ AI โดยเฉพาะเพิ่มขึ้น 81 เปอร์เซ็นต์ Vibe coding ยิ่งเติมเชื้อให้ปัญหา เพราะเอเจนต์ commit โดยไม่ตรวจดู

สิ่งที่ควรตรวจสอบด้วยตนเองตอนนี้:

1. เปิดไฟล์ .gitignore ของโปรเจกต์

   ตรวจให้แน่ใจว่ามีบรรทัด .env หากไม่มี ให้เพิ่มก่อน commit ครั้งแรก

2. ไปที่ repository ของคุณบน GitHub

   ตรวจว่าไม่มีไฟล์ .env อยู่ การค้นหา .env หรือส่วนหนึ่งของคีย์ใน repository เป็นวิธีตรวจสอบที่รวดเร็ว

3. หากคีย์รั่วไหล ให้เพิกถอนและออกคีย์ใหม่

   ลบ commit ยังไม่พอ เพราะอาจมีคนเอาคีย์ไปแล้ว ไปที่บริการนั้น (ผู้ให้บริการชำระเงิน บริการคลาวด์ หรือผู้ให้บริการ AI) เพิกถอนคีย์เก่าและออกคีย์ใหม่ กระบวนการนี้เรียกว่า rotation

4. กำหนดสิทธิ์ให้คีย์เท่าที่จำเป็น

   หากคีย์ใช้สำหรับอ่านอย่างเดียว ให้กำหนดเป็นแบบอ่านอย่างเดียว แบบนี้แม้คีย์รั่วไหล ก็มีข้อมูลให้ขโมยน้อยลง

ทำไมทุกคนจึงเห็นฐานข้อมูลของคุณได้หากไม่มี RLS?#

หากคุณกำลังสร้างแอปบน Supabase หรือฐานข้อมูลที่คล้ายกัน นี่คือส่วนที่สำคัญที่สุด RLS ย่อมาจาก Row Level Security หรือการรักษาความปลอดภัยระดับแถว พูดง่าย ๆ คือกฎที่กำหนดว่าจะแสดงแถวไหนในตารางให้ผู้ใช้คนใด หากไม่มี RLS ตาราง “orders” ก็จะส่งคืนคำสั่งซื้อของลูกค้าทุกคนให้ทุกคน

เอกสารของ Supabase อธิบายไว้อย่างตรงไปตรงมาดังนี้:

นี่คือกับดักสำคัญสำหรับผู้สร้างแบบ vibe coding เมื่อสร้างตารางด้วยการคลิกผ่านแดชบอร์ด Supabase ระบบจะเปิดการป้องกันให้อัตโนมัติ แต่เมื่อ AI สร้างตาราง — ซึ่งแทบทุกครั้งมันจะเขียนคำสั่ง SQL โดยตรง — RLS จะยังปิดอยู่ตามค่าเริ่มต้น นั่นหมายความว่าตารางที่เอเจนต์สร้างแทบจะแน่นอนว่าเปิดให้ทั้งอินเทอร์เน็ตเข้าถึง นี่คือวิธีที่ข้อมูลจากแอป Lovable 170 แอปรั่วไหล

สิ่งที่ควรทำ:

1. ถามเอเจนต์โดยตรง

   เขียนว่า: “แสดงตารางทั้งหมดที่ปิด RLS ไว้ให้ฉันดู” AI จะสร้างรายการให้ นั่นคือรายการงานที่คุณต้องจัดการ

2. เปิด RLS ในทุกตารางที่มีข้อมูลผู้ใช้

   แล้วเพิ่มนโยบายการเข้าถึงอย่างน้อยหนึ่งข้อ เช่น “ผู้ใช้ดูได้เฉพาะแถวข้อมูลของตนเอง”

3. ตรวจสอบแดชบอร์ด

   ในแดชบอร์ด Supabase ทุกตารางควรแสดง “RLS enabled” หากเป็นสีเทาหรือสีแดง แสดงว่าตารางเปิดอยู่

4. ทดสอบจริง

   ลงชื่อเข้าใช้ในฐานะผู้ใช้ทั่วไปแล้วลองขอข้อมูลของคนอื่น หากระบบปฏิเสธการเข้าถึง แสดงว่านโยบายทำงาน

ทำไมการตรวจสอบสิทธิ์ในอินเทอร์เฟซจึงปกป้องคุณไม่ได้?#

ความเข้าใจผิดที่พบบ่อยคือ “ฉันทำให้ผู้ใช้ทั่วไปมองไม่เห็นปุ่มผู้ดูแลระบบแล้ว” ปัญหาคือปุ่มเป็นแค่ภาพในเบราว์เซอร์ คุณส่งคำขอตรงไปยังเซิร์ฟเวอร์ได้โดยไม่ต้องใช้ปุ่ม หากเซิร์ฟเวอร์ไม่ตรวจสอบสิทธิ์ซ้ำ ก็จะดำเนินการตามคำสั่งของคนอื่น

ตัวอย่างคลาสสิกเรียกว่า IDOR ลองนึกภาพว่าคุณเปิดคำสั่งซื้อของตัวเองที่ที่อยู่ซึ่งมี id=123 เปลี่ยนเป็น id=124 แล้วคุณก็เห็นคำสั่งซื้อของคนอื่นได้ เพราะเซิร์ฟเวอร์ไม่ได้ตรวจสอบว่าเป็นคำสั่งซื้อของคุณจริงหรือไม่ นี่คือช่องโหว่ที่พบบ่อยที่สุดอย่างหนึ่งในแอปที่สร้างด้วย vibe coding และการตรวจสอบสิทธิ์ที่ไม่รัดกุมก็เป็นสาเหตุของข้อมูลรั่วไหลใน Tea

กฎนี้เรียบง่าย: ตรวจสอบซ้ำที่เซิร์ฟเวอร์ทุกครั้งว่า “ผู้ใช้นี้มีสิทธิ์ทำสิ่งนี้หรือไม่” อินเทอร์เฟซมีไว้เพื่อความสะดวก ส่วนการป้องกันต้องอยู่ที่ backend ข้อความพร้อมใช้สำหรับสั่งเอเจนต์: “เพิ่มการตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์ให้กับทุก endpoint ที่อ่านหรือเปลี่ยนแปลงข้อมูลผู้ใช้ อย่าอาศัยเพียงการซ่อนองค์ประกอบไว้ในอินเทอร์เฟซ”

หากไม่ใช่โปรแกรมเมอร์ จะตรวจหาโค้ดที่มีช่องโหว่ได้อย่างไร?#

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

1. คำสั่ง /security-review ใน Claude Code ตรวจสอบ branch ปัจจุบันครั้งเดียวเพื่อหา SQL injection, XSS, ช่องโหว่ด้านการอนุญาตสิทธิ์ ข้อมูลรั่วไหล และปัญหาจาก dependencies ฉันอธิบายวิธีทำงานทีละขั้นตอนและวิธีแนบการตรวจสอบอัตโนมัติให้กับทุกการเปลี่ยนแปลงไว้ในคู่มือแยกต่างหากเรื่อง การตรวจสอบความปลอดภัยใน Claude Code ประเด็นสำคัญคือ นี่เป็นแนวป้องกันด่านแรก ซึ่งเรียกใช้ได้ด้วยคำสั่งเดียว

2. ปลั๊กอิน security-guidance อย่างเป็นทางการ ติดตั้งจาก marketplace ปลั๊กอินอย่างเป็นทางการด้วย /plugin install security-guidance@claude-plugins-official (ต้องใช้ Claude Code เวอร์ชัน 2.1.144 ขึ้นไป) ปลั๊กอินตรวจโค้ดในสามจังหวะ: ทุกครั้งที่แก้ไข เมื่อจบแต่ละ turn และตอน commit มันตรวจจับการข้ามการอนุญาตสิทธิ์ IDOR, injection และการเข้ารหัสที่ไม่รัดกุมได้ แต่ Anthropic ก็ระบุข้อจำกัดไว้อย่างตรงไปตรงมา:

จากนั้นบอกเอเจนต์ว่า: “ตรวจหาช่องโหว่ในโปรเจกต์ของฉัน” แต่ชุดนี้มีข้อควรระวังสำคัญ ซึ่งเป็นเหตุผลที่ฉันแยกหัวข้ออธิบายไว้ด้านล่าง

เพื่อให้เห็นภาพ ผู้เล่นรายใหญ่ก็เริ่มให้ความสำคัญกับความปลอดภัยของโค้ด AI เช่นกัน ใน Project Glasswing ซึ่งขยายโครงการเมื่อวันที่ 2 มิถุนายน 2026 ให้มีองค์กรเข้าร่วม 150 แห่ง พันธมิตรพบช่องโหว่ร้ายแรงมากกว่า 10,000 รายการในเวลาไม่นานโดยใช้โมเดลของ Anthropic ความเสี่ยงนั้นชัดเจน:

<figure>
<blockquote>
<p>เราประเมินว่าสำหรับพันธมิตรส่วนใหญ่ การโจมตีครั้งใหญ่อาจส่งผลกระทบต่อผู้คนมากกว่า 100 ล้านคน</p>
</blockquote>
<figcaption>— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing</figcaption>
</figure>

## เชื่อถือทักษะและส่วนขยายจาก GitHub ได้หรือไม่?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

ประเด็นสำคัญ

ไม่ได้ หากไม่มีการตรวจสอบก่อนติดตั้ง ทักษะ ปลั๊กอิน หรือส่วนขยายใด ๆ ก็คือโค้ดของคนอื่น ซึ่งเอเจนต์จะเรียกใช้บนเครื่องของคุณด้วยสิทธิ์ของคุณ ชุดที่มีคำว่า “Anthropic” อยู่ในชื่อแท้จริงแล้วสร้างโดยชุมชนและไม่มีส่วนเกี่ยวข้องกับ Anthropic ส่วนขยายที่เป็นอันตรายอาจขโมยคีย์ของคุณภายในไม่กี่นาที และการลบแพ็กเกจก็ไม่ได้กำจัดมันออกไปเสมอไป

</div>

เรื่องนี้ซับซ้อนเป็นพิเศษ เพราะอันตรายมาจากเครื่องมือที่คุณติดตั้งเพื่อรักษาความปลอดภัย เมื่อคุณเรียกใช้ `npx skills add ...` หรือติดตั้งส่วนขยาย คุณกำลังนำโค้ดของคนอื่นเข้ามา แล้วเอเจนต์ก็เรียกใช้โค้ดนั้นด้วยสิทธิ์ของคุณ หากผู้เขียนถูกแฮ็กหรือแพ็กเกจเป็นอันตรายมาตั้งแต่แรก คุณก็มีปัญหาแล้ว

ลองดูชุดทักษะจากหัวข้อก่อนหน้า ชื่อของชุดนี้มีคำว่า “Anthropic” ซึ่งทำให้คุณลดการระวังตัวลง แต่คำอธิบายของชุดนั้นเองระบุไว้อย่างชัดเจนว่า:

<figure>
<blockquote>
<p>นี่เป็นโปรเจกต์ชุมชนอิสระ และไม่มีส่วนเกี่ยวข้องกับ Anthropic PBC</p>
</blockquote>
<figcaption>— README ของ repository mukul975</figcaption>
</figure>

กล่าวอีกอย่างคือ ชื่อนี้ทำให้เข้าใจผิด ตัวชุดเองมีความพร้อมและสะอาดดีในขณะนี้ แต่หลักการยังคงเดิม: คุณติดตั้งโดยยอมรับความเสี่ยงเอง และภัยคุกคามก็ไม่ใช่เรื่องสมมติ ในเดือนพฤษภาคม 2026 ส่วนขยายโปรแกรมแก้ไขที่เป็นอันตรายอยู่ใน marketplace เพียง 18 นาที แต่ในช่วงเวลานั้นก็ขโมยรหัสผ่านจากตัวจัดการรหัสผ่าน โทเคน GitHub สิทธิ์เข้าถึงคลาวด์ และแม้แต่การกำหนดค่า Claude Code จากผู้ที่ติดตั้งไปได้ อีกเรื่องที่น่ากังวลคือมัลแวร์ประเภทนี้มักอยู่รอดได้แม้ลบแพ็กเกจตามปกติ และกลับมาทำงานอีกครั้งในเซสชันถัดไป

ฉันสร้างนิสัยง่าย ๆ ให้ตัวเอง และแนะนำให้คุณทำเช่นกัน: ก่อนติดตั้งทักษะใด ๆ จาก GitHub ให้ตรวจสอบด้วยตัวเอง ผู้เขียนอาจถูกแฮ็ก บัญชีอาจถูกยึด และมัลแวร์อาจถูกใส่ไว้ใน repository การตรวจสอบช่วยปกป้องคุณได้

สิ่งขั้นต่ำที่ควรทำก่อนติดตั้ง: ดูผู้เขียนและจำนวนดาว อ่านคำอธิบายของทักษะ อย่าติดตั้งเครื่องมือ “เพราะมีคนแนะนำไว้ในโพสต์เดียว” และสำหรับเครื่องมือที่ไม่คุ้นเคย ให้ลองใช้ในสภาพแวดล้อมทดสอบที่แยกต่างหากก่อน ไม่ใช่บนเครื่องที่มีคีย์ production

## สิ่งที่จะช่วยคุณหลังถูกเจาะระบบ: การสำรองข้อมูลและย้อนกลับ

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

ประเด็นสำคัญ

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

</div>

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

เรื่องนี้นำไปสู่กฎสองข้อ

**สำรองข้อมูลบ่อย ๆ** หากแอปมีข้อมูลที่คุณไม่อยากเสีย การมีสำเนาทุกสามวันเป็นเพียงภาพลวงตาของการปกป้อง ตั้งค่าการสำรองข้อมูลอัตโนมัติอย่างน้อยทุก 30 นาที ฐานข้อมูลส่วนใหญ่ รวมถึง Supabase เปิดใช้ฟังก์ชันนี้ได้ด้วยการคลิกไม่กี่ครั้ง

**Git คือประกันภัยจากเอเจนต์** Git เก็บประวัติโค้ดของคุณ คุณจึงกู้คืนสถานะที่ใช้งานได้ทุกสถานะ เมื่อเอเจนต์เขียนทับสิ่งที่เคยทำงานได้ คุณก็ย้อนกลับไปยังเวอร์ชันล่าสุดที่ใช้งานได้ แทนการแก้ด้วยมือ หาก AI ลบหรือทำโปรเจกต์พังและคุณไม่รู้วิธีกู้คืน ให้ดูรายงานแยกเรื่อง [ต้องทำอย่างไรหาก AI ลบฐานข้อมูล](guide-032.md) หากต้องการป้องกันโปรเจกต์พังล่วงหน้า โปรดดูคู่มือ [วิธีป้องกัน Claude Code ไม่ให้ทำของพัง](guide-154.md)

## รายการตรวจสอบความปลอดภัยก่อนเผยแพร่

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

ประเด็นสำคัญ

ก่อนเปิดแอปให้สาธารณะใช้งาน ให้ตรวจ 10 ข้อ: เก็บความลับไว้ใน `.env` และใส่ `.env` ใน `.gitignore` เปิดใช้ RLS ตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์ ตรวจสอบลายเซ็น webhook จำกัดสิทธิ์ของคีย์และเอเจนต์ให้เหลือเท่าที่จำเป็น สำรองข้อมูลให้เป็นปัจจุบัน ตรวจโค้ดด้วยเครื่องมือ และระมัดระวังทักษะของผู้อื่น นี่เป็นรายการตรวจพื้นฐานก่อนเผยแพร่ ไม่มีเปอร์เซ็นต์ความครอบคลุมที่วัดแล้วหรือเวลาจบที่รับประกัน ต้องทดสอบสถานการณ์เข้าถึงจริงในแอป ช่องที่ติ๊กไว้ไม่ได้พิสูจน์การป้องกัน

</div>

ตรวจรายการนี้ก่อนเผยแพร่ทันที ตามลำดับ

1.  **เก็บข้อมูลลับไว้ใน `.env` และใส่ `.env` ใน `.gitignore`** ไม่มีคีย์ในโค้ด ไม่มีไฟล์ `.env` ใน repository สาธารณะ
2.  **คีย์มีสิทธิ์เท่าที่จำเป็น** คีย์แต่ละตัวทำได้เฉพาะสิ่งที่ต้องทำ คีย์ production แยกจากสภาพแวดล้อมของเอเจนต์
3.  **เปิดใช้ RLS** ในทุกตารางที่มีข้อมูลผู้ใช้ และกำหนดนโยบายการเข้าถึงไว้แล้ว
4.  **ตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์** สำหรับทุกการดำเนินการกับข้อมูล การซ่อนปุ่มในอินเทอร์เฟซยังไม่พอ ทดสอบการเปลี่ยน `id` ในที่อยู่ด้วยตนเองแล้ว
5.  **ตรวจสอบลายเซ็น webhook** ตัวจัดการการแจ้งเตือนภายนอกทั้งหมด (การชำระเงิน แบบฟอร์ม) ตรวจสอบลายเซ็น



6.  **จำกัดอัตราการเรียกใช้** สำหรับคำขอขาเข้าและการดำเนินการที่มีค่าใช้จ่ายสูง เพื่อไม่ให้เดารหัสผ่านแบบ brute force ได้ และไม่ให้ยอดเรียกเก็บเงินพุ่งสูง
7.  **เอเจนต์ไม่ได้ทำงานในโหมด “อนุญาตทุกอย่าง”** บนเครื่องที่มีคีย์ production และปฏิเสธการอ่าน `.env` แล้ว
8.  **สำรองข้อมูล** บ่อยครั้งและทดสอบแล้ว — คุณได้ลองกู้คืนจริง ไม่ใช่แค่เชื่อว่าสำเนา “อยู่ที่ไหนสักแห่ง”
9.  **ตรวจโค้ดแล้ว** ด้วย `/security-review` หรือปลั๊กอิน security-guidance และแก้ไขสิ่งที่ตรวจพบแล้ว
10. **ตรวจทักษะและส่วนขยายของผู้อื่นแล้ว** ก่อนติดตั้ง ไม่มีอะไรที่ติดตั้งไปโดย “ไม่ตรวจสอบ”

<div class="aside" data-semantic="callout" role="note" aria-label="เคล็ดลับ">

เคล็ดลับ

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

</div>

## วันนี้ควรเริ่มตรงไหน

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

ประเด็นสำคัญ

เริ่มจากสามเรื่องที่ปิดช่องโหว่ทั่วไปและมีค่าใช้จ่ายสูงที่สุด: ตรวจว่า `.env` ไม่ได้อยู่ใน repository สาธารณะ ถามเอเจนต์ว่าตารางไหนปิด RLS ไว้ และตั้งค่าการสำรองข้อมูลให้ถี่กว่าวันละครั้ง การตรวจเหล่านี้เป็นจุดเริ่มที่มีประโยชน์ แต่เวลาและความครอบคลุมขึ้นกับแอป ต้องตามด้วยการทดสอบสิทธิ์จริงและการกู้คืน

</div>

อย่าพยายามทำทุกอย่างในคู่มือนี้ให้เสร็จภายในคืนเดียว เพราะสุดท้ายคุณจะไม่ได้ทำอะไรเลย วันนี้ให้ทำสามขั้นตอนที่สำคัญที่สุด:

1.  **ตรวจข้อมูลลับของคุณ** เปิด `.gitignore` ตรวจให้แน่ใจว่ามี `.env` และตรวจว่าไม่มีคีย์อยู่ใน repository สาธารณะ หากคีย์รั่วไหล ให้เพิกถอนและออกคีย์ใหม่
2.  **ถามเกี่ยวกับ RLS** บอกเอเจนต์ว่า: “แสดงตารางที่ปิด RLS ไว้ให้ฉันดู” แล้วเปิด RLS ทุกตารางที่เก็บข้อมูลของผู้คน
3.  **ตั้งค่าการสำรองข้อมูลบ่อย ๆ** เพื่อให้เมื่อเกิดปัญหา คุณเสียเวลาเป็นนาทีแทนที่จะเป็นวัน

จากนั้นทำตามรายการตรวจสอบข้างต้นเมื่อโปรเจกต์ของคุณเติบโตและเริ่มจัดการเงินกับข้อมูลของผู้อื่น

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

<div class="section" role="doc-bibliography" aria-label="แหล่งที่มา">

### แหล่งที่มา

- [วิธีที่ Anthropic ควบคุม Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [การขยาย Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: สิทธิ์และกฎ deny (เอกสารประกอบ)](https://code.claude.com/docs/en/permissions)
- [ปลั๊กอิน security-guidance (เอกสาร Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (เอกสาร Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 สำหรับแอปพลิเคชัน LLM ปี 2025](https://genai.owasp.org/llm-top-10/)

</div>





หากต้องการทำงานกับโมเดลต่อไป ไปที่ [Ailoot](https://ailoot.ai/)