CORS​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ ​Frontend​ ​จึง​เรียก​ ​API​ ​บาง​ตัว​ไม่​ได้

CORS (Cross-Origin Resource Sharing) เป็นกลไก HTTP Header ที่ให้ Server บอก Browser ว่าหน้าเว็บจาก Origin อื่นเรียกทรัพยากรได้หรือไม่ Origin ประกอบด้วย Scheme, Host และ Port ดังนั้น https://app.example.com กับ https://api.example.com เป็นคนละ Origin แม้จะเป็นธุรกิจเดียวกัน

Browser ตรวจอะไร

เมื่อ JavaScript บนหน้าเว็บเรียก API ข้าม Origin Browser ใช้กติกา Same-Origin Policy และดู Header ตอบกลับของ Server บางคำขอมี Preflight เป็น OPTIONS เพื่อตรวจ Method กับ Header ก่อนส่งคำขอจริง หาก Server ไม่ตอบตามเงื่อนไข Browser จะไม่ให้ JavaScript อ่านผล แม้ Server อาจได้รับบางคำขอแล้วก็ตาม จึงต้องวิเคราะห์ Network Log ไม่เดาจากข้อความ Error อย่างเดียว

ภาพที่ 1: CORS เป็นการอนุญาตระดับ Origin ใน Browser ก่อนให้สคริปต์อ่านผลจาก API

ตัวอย่างสมมติ: เว็บกับ API คนละโดเมน

หน้าเว็บอยู่ https://app.example.com แต่ API อยู่ https://api.example.com Server ต้องอนุญาต Origin ที่ต้องใช้จริงและตอบ Header ให้สอดคล้องกับคำขอ หากใช้ Cookie ข้าม Origin ยังต้องพิจารณาการส่ง Credential และนโยบาย Cookie เพิ่ม ไม่ควรเปิดอนุญาตทุก Origin เพื่อแก้ Error โดยไม่ดูว่าข้อมูลหรือ Credential ใดเกี่ยวข้อง

CORS ไม่ใช่อะไร

CORS ไม่ได้แทนการ Login หรือการตรวจสิทธิ์ของข้อมูล Client ที่ไม่ใช่ Browser อาจเรียก API โดยไม่อยู่ภายใต้กติกา CORS แบบเดียวกัน จึงต้องป้องกัน API ด้วย Authentication และ Authorization เอง การแก้ CORS ที่ Frontend ฝ่ายเดียวมักไม่พอ เพราะ Server เป็นฝ่ายประกาศ Origin ที่อนุญาต

สำหรับรายงาน

ระบุ Origin ต้นทางและปลายทาง Method/Header ที่ใช้ ผล Preflight และ Header ตอบกลับ แยกสาเหตุ CORS ออกจาก Error เครือข่าย 401 หรือ 403 เพื่อเสนอการแก้ถูกจุด หลีกเลี่ยงการใช้คำว่า “ปิด CORS” โดยไม่อธิบายผลต่อข้อมูล

อ่าน REST API และ Authentication กับ Authorization หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ Request origin, preflight OPTIONS และ response headers ที่จำเป็น ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ Browser อ่าน response ได้เฉพาะ origin และ method ที่อนุญาต ส่วนข้อจำกัดที่ต้องระบุคือ CORS เป็นนโยบาย Browser ไม่ใช่กลไกยืนยันตัวตนของ API หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• MDN: Cross-Origin Resource Sharing — Origin, Preflight และ Header CORS