เช็กลิสต์ความปลอดภัยสำหรับแอปที่สร้างด้วย AI: ตรวจอะไรก่อนเปิดตัว

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

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

วิธีใช้เช็กลิสต์นี้

ทำตามลำดับ และสำหรับแต่ละข้อให้ทำสองอย่าง: ถาม AI เพื่อให้มั่นใจว่าจัดการแล้ว และ ทดสอบด้วยตนเอง AI เขียนการตรวจสิทธิ์ได้ แต่มีเพียงการทดสอบเท่านั้นที่บอกว่ามันทำงานจริง ข้อต่างๆ มีเครื่องหมายดังนี้

• Must ทำก่อนที่ใครอื่นจะใช้แอป
• Should ทำก่อนที่คุณจะมีผู้ใช้จริงหรือข้อมูลจริง
• Later ควรทำเมื่อแอปเติบโตขึ้น

หากมีเวลาแค่หนึ่งชั่วโมง ให้ทำทุกข้อที่เป็น Must

1. การยืนยันตัวตน: เขาคือใคร

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

• Must: ทุกหน้าที่แสดงข้อมูลส่วนตัวต้องการการเข้าสู่ระบบ ทดสอบ: ออกจากระบบ แล้ววาง URL ของหน้าส่วนตัวลงในเบราว์เซอร์โดยตรง
• Must: ทุก API endpoint ที่อยู่หลังหน้าเหล่านั้นก็ต้องการการเข้าสู่ระบบด้วย ไม่ใช่แค่หน้า ทดสอบ: ออกจากระบบ เปิดแท็บ network ของเบราว์เซอร์ แล้วลองส่งคำขอที่แอปส่งไว้ตอนที่คุณเข้าสู่ระบบอยู่
• Must: รหัสผ่านถูกเก็บในรูปแบบแฮชด้วยอัลกอริทึมแฮชรหัสผ่านที่ช้า ไม่ใช่เป็นข้อความธรรมดา แนวทางการเก็บรหัสผ่านของ OWASP แนะนำ Argon2id เป็นอันดับแรก และ scrypt, bcrypt หรือ PBKDF2 เป็นทางเลือก ถามว่า “รหัสผ่านถูกเก็บอย่างไร”
• Should: ลิงก์รีเซ็ตรหัสผ่านหมดอายุและใช้ได้เพียงครั้งเดียว
• Should: คุกกี้เซสชันมีการตั้งค่า Secure, HttpOnly และ SameSite และการออกจากระบบจะยุติเซสชันบนเซิร์ฟเวอร์
• Later: เสนอการยืนยันตัวตนสองขั้นตอน หรือการเข้าสู่ระบบผ่านผู้ให้บริการที่มีฟีเจอร์นี้

ตรวจทุก API route และหน้าที่ส่งข้อมูลผู้ใช้กลับมา แต่ละรายการต้องปฏิเสธคำขอจากผู้ใช้ที่ยังไม่ได้เข้าสู่ระบบ ที่เซิร์ฟเวอร์ ไม่ใช่แค่ในโค้ดของหน้า ลิสต์ route ที่คุณตรวจแล้ว

2. การอนุญาต: เขาทำอะไรได้บ้าง

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

• Must: ทุกการอ่าน อัปเดต และลบ ตรวจบนเซิร์ฟเวอร์ว่าเรคอร์ดเป็นของผู้ใช้ปัจจุบัน (หรือทีมของเขา)
• Must: ทดสอบ: สร้างบัญชีสองบัญชี คือ A และ B ในฐานะ A ให้เปิดเรคอร์ดหนึ่งของ A แล้วจดค่า ID ที่อยู่ใน URL หรือคำขอเครือข่าย จากนั้นเข้าสู่ระบบเป็น B แล้วขอ ID เดียวกัน B ต้องได้รับข้อผิดพลาด ไม่ใช่ข้อมูลของ A
• Must: หน้าผู้ดูแลระบบและ API endpoint ของผู้ดูแลตรวจบทบาทของผู้ใช้บนเซิร์ฟเวอร์ การซ่อนลิงก์ผู้ดูแลไม่ใช่การป้องกัน
• Must: ผู้ใช้เปลี่ยนบทบาท ราคา ยอดคงเหลือ หรือฟิลด์เจ้าของของตัวเองไม่ได้ โดยการแก้ไขคำขอ ทดสอบ: ในแท็บ network ดูว่าการอัปเดตโปรไฟล์ส่งอะไรไปบ้าง หากมีฟิลด์อย่าง role หรือ isAdmin ให้ขอ AI ให้ละเว้นฟิลด์เหล่านั้นจากฝั่งไคลเอนต์
• Should: ID ใน URL เดาได้ยาก (ใช้ ID แบบสุ่มแทน 1, 2, 3) นี่ไม่ใช่การทดแทนการตรวจสิทธิ์ แต่ช่วยจำกัดความเสียหายเมื่อขาดการตรวจสิทธิ์

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

3. การเข้าถึงระดับแถวในฐานข้อมูล

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

ทำได้ดีทั้งสองวิธี สิ่งที่สำคัญคือ

• Must: หากเบราว์เซอร์คุยกับฐานข้อมูลโดยตรง (ฐานข้อมูลแบบโฮสต์บางตัวอนุญาตให้ทำได้) กฎ row-level ต้องเปิดใช้งานทุกตาราง ไม่เช่นนั้นใครก็ตามที่มี public key อ่านทั้งตารางได้
• Must: คำค้นกรองตามผู้ใช้หรือทีมปัจจุบัน ไม่ใช่ตามค่า ID ที่เบราว์เซอร์ส่งมา
• Should: ข้อมูลที่ใช้ร่วมกัน (โปรเจกต์ของทีม) มีกฎที่ชัดเจนว่าใครอยู่ในทีม และบังคับใช้ในที่เดียว

4. ความลับและคีย์ API

คีย์ API คือรหัสผ่านของบริการหนึ่ง Stripe ระบบอีเมล และผู้ให้บริการ AI ล้วนใช้คีย์เหล่านี้ เพื่อความเข้าใจพื้นฐาน ดู ตัวแปรสภาพแวดล้อมและความลับคืออะไร

• Must: คีย์ถูกเก็บในตัวแปรสภาพแวดล้อมหรือส่วนลับของโปรเจกต์ ไม่เขียนลงในโค้ด
• Must: คีย์ที่ใช้จ่ายเงินหรืออ่านข้อมูลส่วนตัวได้ ใช้เฉพาะบนเซิร์ฟเวอร์ ทดสอบ: เปิดเว็บที่ใช้งานจริง ดู page source และไฟล์ JavaScript ในเครื่องมือนักพัฒนา แล้วค้นหาจุดเริ่มต้นของคีย์ของคุณ (เช่น sk_) ต้องไม่ปรากฏ
• Must: ไม่เคยวางคีย์ในแชท repository สาธารณะ หรือภาพหน้าจอ หากเคยทำ ให้ หมุนเวียนคีย์ ที่ผู้ให้บริการ (สร้างคีย์ใหม่ แล้วลบคีย์เก่า)
• Should: ใช้คีย์แบบจำกัดขอบเขตหรือจำกัดสิทธิ์ เมื่อผู้ให้บริการมีตัวเลือกนี้ เช่น Stripe แนะนำให้ใช้ restricted key ที่มีเฉพาะสิทธิ์ที่การผสานการทำงานของคุณต้องใช้
• Should: คีย์ทดสอบและคีย์จริงแยกกัน และแอปที่ใช้งานจริงจะใช้คีย์จริงเมื่อคุณพร้อมเท่านั้น

คีย์บางตัวออกแบบมาให้เปิดเผยได้ เช่น publishable key ของ Stripe (pk_…) หรือคีย์แผนที่ที่จำกัดเฉพาะโดเมนของคุณ กฎนี้ใช้กับคีย์ที่ให้อำนาจ ไม่ใช่ทุกสตริงที่หน้าตาเหมือนคีย์

5. การตรวจสอบอินพุต

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

• Must: การตรวจสอบเกิดขึ้นบนเซิร์ฟเวอร์ ไม่ใช่แค่ในเบราว์เซอร์ การตรวจในเบราว์เซอร์มีไว้เพื่อความสะดวก ใครก็ข้ามได้
• Must: การค้นหาในฐานข้อมูลใช้พารามิเตอร์ ไม่ใช่การต่อข้อความจากอินพุตของผู้ใช้เข้าด้วยกัน (วิธีนี้ป้องกัน SQL injection) ขอให้ AI ยืนยัน
• Must: ข้อความที่ผู้ใช้กรอกถูกแสดงเป็นข้อความ ไม่ถูกรันเป็น HTML ทดสอบ: กรอก <b>hello</b> เป็นชื่อของคุณ คุณควรเห็นแท็กเหล่านั้น ไม่ใช่ตัวหนา
• Should: การอัปโหลดไฟล์ตรวจชนิดและขนาด และไฟล์ที่อัปโหลดไม่ถูกให้บริการจากโดเมนหลักของแอปในรูปแบบหน้าที่รันได้
• Should: ข้อผิดพลาดที่แสดงต่อผู้ใช้เป็นข้อความธรรมดา (“เกิดข้อผิดพลาด”) รายละเอียดเชิงลึกไปอยู่ในบันทึกของเซิร์ฟเวอร์เท่านั้น
• Should: เว็บฮุกจากบริการอย่าง Stripe ตรวจลายเซ็นของผู้ให้บริการก่อนดำเนินการ ดู เว็บฮุกคืออะไร

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

6. การจำกัดอัตราและการใช้งานในทางที่ผิด

การจำกัดอัตรา (rate limit) คือการกำหนดเพดานจำนวนคำขอที่ใครคนหนึ่งส่งได้ในช่วงเวลาหนึ่ง หากไม่มีการจำกัด ใครก็ได้จะเดารหัสผ่านทั้งวัน ถล่มฟอร์มสมัครสมาชิก หรือทำให้บิลของ API ที่เสียเงินพุ่ง

• Must: การเข้าสู่ระบบ การสมัครสมาชิก และการรีเซ็ตรหัสผ่านถูกจำกัดอัตราต่อที่อยู่ IP และต่อบัญชี
• Must: ทุกอย่างที่มีค่าใช้จ่ายต่อการเรียกใช้ เช่น คำขอโมเดล AI, SMS, อีเมล มีขีดจำกัดต่อผู้ใช้ และต้องเข้าสู่ระบบก่อน
• Should: ฟอร์มสาธารณะ (ติดต่อเรา รายชื่อรอ) มีการป้องกันสแปม เช่น การจำกัดอัตรา ฟิลด์ honeypot ที่ซ่อนไว้ หรือ CAPTCHA
• Should: ตั้งเพดานการใช้จ่ายหรือการแจ้งเตือนกับผู้ให้บริการที่เสียเงินทุกราย เพื่อไม่ให้บั๊กหรือผู้โจมตีทำให้บิลไม่มีที่สิ้นสุด

7. Dependencies

แอปถูกสร้างจากแพ็กเกจโอเพนซอร์ส และบางครั้งแพ็กเกจมีช่องโหว่ที่รู้กันอยู่

• Should: ขอให้ AI ตรวจช่องโหว่ที่รู้จัก (สำหรับโปรเจกต์ JavaScript ใช้ npm audit หรือคำสั่งที่เทียบเท่าของตัวจัดการแพ็กเกจของคุณ) และอัปเดตส่วนที่ได้รับผลกระทบ
• Should: ลบแพ็กเกจที่แอปไม่ได้ใช้แล้ว
• Should: ระวังแพ็กเกจที่มีผู้ใช้น้อยมาก หรือชื่อที่ดูคล้ายการพิมพ์ผิดของแพ็กเกจยอดนิยม
• Later: ตรวจซ้ำทุกหนึ่งหรือสองเดือน หรือเปิดการแจ้งเตือนอัตโนมัติ หากโค้ดของคุณอยู่บน GitHub

8. การสำรองข้อมูลและการกู้คืน

ความปลอดภัยรวมถึงการกู้คืนจากความผิดพลาด ไม่ว่าจะของคุณ ของ AI หรือของผู้โจมตี

• Must: รู้ว่าข้อมูลของคุณอยู่ที่ใดและมีการสำรองหรือไม่ อย่าคิดเอาเอง ให้ตรวจในเอกสารของผู้ให้บริการโฮสต์
• Should: เก็บการส่งออกข้อมูลสำคัญเป็นระยะด้วยตนเอง (เช่น ฟีเจอร์ส่งออก CSV หรือการดัมพ์ฐานข้อมูล) และเก็บแยกจากระบบหลัก
• Should: เก็บโค้ดไว้ใน version control เพื่อกู้คืนเวอร์ชันใดก็ได้
• Should: การกระทำที่ลบถาวร (ลบบัญชี ลบโปรเจกต์) ขอให้ยืนยันก่อน และพิจารณาการลบแบบ “soft delete” ที่เลิกทำได้ในช่วงเวลาหนึ่ง
• Later: ทดสอบการกู้คืนจริงหนึ่งครั้ง การสำรองข้อมูลที่ไม่เคยกู้คืนจริงเป็นเพียงความหวัง ไม่ใช่แผน

9. ก่อนเปิดตัว

• Must: เว็บที่ใช้งานจริงใช้ HTTPS ทุกที่
• Must: ข้อมูลตัวอย่าง บัญชีทดสอบ และหน้าดีบักจากการพัฒนาถูกลบออก
• Should: นโยบายความเป็นส่วนตัวระบุว่าคุณเก็บข้อมูลอะไรและเพื่ออะไร ซึ่งจำเป็นในหลายพื้นที่หากคุณเก็บข้อมูลส่วนบุคคล อย่าอ้างการรับรองที่คุณไม่มี (SOC 2, HIPAA)
• Should: มีช่องทางให้ติดต่อเรื่องปัญหาความปลอดภัย และคุณรู้วิธีหมุนเวียนคีย์ทุกตัวได้อย่างรวดเร็ว

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

เมื่อไรควรให้ผู้เชี่ยวชาญตรวจ

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

ความปลอดภัยเมื่อสร้างบน Mythex

Mythex ไม่มีแผงสแกนความปลอดภัย ดังนั้นเช็กลิสต์ด้านบนคือขั้นตอนที่ควรทำตาม สิ่งที่ช่วยได้มีดังนี้

• ความลับของโปรเจกต์ เก็บคีย์ไว้ที่ การตั้งค่าโปรเจกต์ → Secrets หรือผ่านการ์ด secrets ที่เอเจนต์แสดงในแชท เพื่อไม่ให้อยู่ในโค้ดหรือข้อความ หลังเปลี่ยนความลับของแอปที่ใช้งานจริง ให้เผยแพร่ใหม่
• โหมด Plan และ Ask ขอให้เอเจนต์ทบทวนสิทธิ์โดยไม่แก้ไข: “ในโหมด Ask ให้ลิสต์ทุก API route และการตรวจสิทธิ์ที่แต่ละรายการทำ”
• /test ให้เอเจนต์คลิกผ่านพรีวิวของคุณในฐานะผู้ใช้ มีประโยชน์สำหรับการทดสอบด้วยบัญชีสองบัญชีในส่วนที่ 2
• Checkpoints ช่วยให้คุณย้อนการเปลี่ยนแปลงที่ทำให้บางอย่างพัง

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

คำถาม