เตือนภัยนักพัฒนา! เมื่อ AI พยายามแก้ปัญหา CORS ผิดวิธีด้วยการสะท้อน Origin
การปล่อยให้ AI แก้ปัญหา CORS อย่างรวดเร็วอาจนำมาซึ่งช่องโหว่ความปลอดภัยระดับวิกฤตโดยไม่รู้ตัว หลังพบพฤติกรรมการตั้งค่าเปิดรับคำขอจากทุกที่พ่วงเครดิต
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- AI มักแก้ปัญหา CORS ด้วยวิธีลัดที่อันตราย เช่น การทำ Origin Reflection
- การใช้ Wildcard ร่วมกับ Credentials ถูกเบราว์เซอร์บล็อก จึงต้องใช้เทคนิคสะท้อนค่าแทน
- ควรแก้ไขด้วยการกำหนดรายการโดเมนที่เชื่อถือได้อย่างชัดเจนทั้งในระบบ Dev และ Prod
ปัญหาเรื่อง Cross-Origin Resource Sharing หรือ CORS ถือเป็นเรื่องชวนปวดหัวสำหรับนักพัฒนาที่ทำโปรเจกต์แยกส่วนระหว่างหน้าบ้านและหลังบ้าน เมื่อเกิดอาการเบราว์เซอร์บล็อกคำขอเนื่องจากอยู่คนละพอร์ต หลายคนมักหันไปพึ่งพาผู้ช่วยปัญญาประดิษฐ์อย่าง Cursor ให้ช่วยแก้ไข ซึ่ง AI มักจะจัดการให้เสร็จสิ้นอย่างรวดเร็วภายในพริบตา ทำให้ข้อผิดพลาดหายไปและนักพัฒนาสามารถเดินหน้าเขียนฟีเจอร์อื่นต่อได้ทันที
ทว่าความจริงเบื้องหลังการแก้ปัญหาอย่างรวดเร็วนั้นกลับซ่อนความเสี่ยงเอาไว้ เนื่องจาก AI ไม่ได้ทำการจำกัดสิทธิ์หรือระบุโดเมนของหน้าบ้านไว้อย่างเจาะจง แต่กลับเลือกวิธีที่ทำให้เซิร์ฟเวอร์ยอมรับคำขอจากแหล่งใดก็ได้พร้อมกับแนบ คุกกี้ (Cookies) มาด้วย เพื่อให้โค้ดสามารถรันผ่านไปได้โดยไม่ต้องเสียเวลาคิดว่าควรอนุญาตโดเมนใดบ้าง ซึ่งข้อมูลลักษณะนี้มีอยู่ล้น
- Stack Overflow
- คลังโค้ดตัวอย่าง
- บทความสอนใช้งานแบบรวดเร็ว
รูปแบบที่มักตรวจพบคือ Origin Reflection แทนที่จะเป็น Wildcard ธรรมดา เนื่องจากเบราว์เซอร์จะบล็อกการใช้งาน Access-Control-Allow-Origin ร่วมกับ Access-Control-Allow-Credentials ทันทีหากตั้งค่าเป็นเครื่องหมายดอกจัน (*) โค้ดตัวอย่างทั่วไปจึงแก้ด้วยการสะท้อนค่า Origin ที่ถูกส่งมาจากคำขอคืนกลับไปตรงๆ ซึ่งวิธีนี้ทำให้ผ่านการทดสอบในเครื่องระหว่างพัฒนา (Local Development) ได้อย่างไร้รอยต่อ และเล็ดลอดผ่านการทดสอบก่อนนำขึ้นใช้งานจริงไปได้
การพึ่งพา AI แก้โค้ดแบบเร่งด่วนโดยไม่ตรวจสอบความปลอดภัยเบื้องหลัง อาจทำให้ระบบหลังบ้านเปิดกว้างต่อภัยคุกคามโดยไม่รู้ตัว นักพัฒนาควรทำความเข้าใจว่า CORS ไม่ใช่ระบบยืนยันตัวตน แต่เป็นเกราะป้องกันชั้นที่สอง ดังนั้นการตรวจสอบโค้ดด้วยเครื่องมือเสริมความปลอดภัยก่อนคอมมิตจึงเป็นสิ่งสำคัญที่ไม่ควรมองข้าม
แนวทางแก้ไขที่ถูกต้องคือการกำหนดรายการโดเมนที่เชื่อถือได้แบบตายตัว ดังตัวอย่างการตั้งค่าใน Flask-CORS:
CORS(app, origins=["https://app.example.com", "https://admin.example.com"], supports_credentials=True)
สำหรับการพัฒนาในเครื่อง ให้เพิ่มพอร์ต localhost ลงในรายการอนุญาตอย่างชัดเจนโดยใช้ตัวแปรสภาพแวดล้อม (Environment Variables) แยกกันระหว่างโหมดพัฒนาและโหมดใช้งานจริง นอกจากนี้ สำหรับผู้ที่ต้องการตรวจสอบโค้ดอัตโนมัติ สามารถใช้เครื่องมือเช่น SafeWeave ที่เชื่อมต่อกับ Cursor และ Claude Code รวมไปถึงการใช้ Pre-commit hook ร่วมกับ Semgrep และ Gitleaks เพื่อช่วยตรวจจับรูปแบบโค้ดที่มีความเสี่ยงเหล่านี้ได้ตั้งแต่เนิ่นๆ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น