การทำความเข้าใจนโยบาย Cross-Origin Resource Sharing (CORS)
นโยบาย CORS เป็นกลไกความปลอดภัยของเว็บเบราว์เซอร์ที่ควบคุมการเข้าถึงทรัพยากรข้ามแหล่งที่มา ตัวตรวจสอบ CORS ช่วยให้คุณวิเคราะห์ว่าเบราว์เซอร์จะอนุญาตหรือบล็อกคำขอ HTTP ที่เฉพาะเจาะจง โดยพิจารณาจากส่วนหัวการตอบกลับ (Response Headers) และรายละเอียดของคำขอที่คุณระบุ เครื่องมือนี้มีประโยชน์อย่างยิ่งสำหรับนักพัฒนาเว็บทั้ง Front-end, Back-end, API platform และ Operations ที่ต้องการตรวจสอบสิทธิ์การอ่านข้อมูลของโค้ดในเบราว์เซอร์ หรือตรวจสอบว่าการตอบกลับแบบ OPTIONS อนุญาตเมธอดและส่วนหัวในขั้นตอนพรีไฟลต์ (Preflight) หรือไม่
การประมวลผลทั้งหมดเกิดขึ้นภายในเบราว์เซอร์ของคุณโดยตรง ส่วนหัวและรายละเอียดคําขอของคุณจะอยู่ในเบราว์เซอร์ของคุณ ไม่มีอะไรถูกอัปโหลดหรือบันทึกโดย BroBroGo เครื่องมือนี้จะตรวจสอบเฉพาะข้อมูลที่คุณป้อนเท่านั้น ไม่ได้ทำการติดต่อเซิร์ฟเวอร์จริง ไม่มีการอ่าน URL ไม่มีการตั้งค่าคุกกี้ ไม่ได้ตรวจสอบ DNS/TLS หรือแก้ไขการกำหนดค่าใดๆ ของเซิร์ฟเวอร์
ข้อมูลนำเข้าและข้อจำกัดของระบบ
เพื่อทำการตรวจสอบนโยบาย CORS คุณต้องระบุข้อมูลนำเข้าในส่วนต่างๆ ดังนี้:
- การตอบสนองเพื่อตรวจสอบ: เลือกระหว่าง "การตอบกลับจริง" หรือ "การตอบกลับพรีไฟลต์"
- HTTP ส่วนหัวการตอบกลับ: วางส่วนหัวการตอบกลับ HTTP ที่ได้จากเซิร์ฟเวอร์ (จำกัดความยาวสูงสุดไม่เกิน 200,000 ตัวอักษร) หากตรวจสอบการตอบกลับพรีไฟลต์ ต้องวางบรรทัดสถานะ (Status Line) ลงไปด้วย
- หากไม่มีข้อมูล จะแสดงข้อผิดพลาด: "วางส่วนหัวการตอบกลับ HTTP ก่อนตรวจสอบ"
- หากข้อมูลยาวเกินไป จะแสดงข้อผิดพลาด: "การตอบสนองนี้มีขนาดใหญ่ผิดปกติ เก็บไว้ใต้อักขระ
‹max›ตัว" - หากรูปแบบบรรทัดไม่ถูกต้อง จะแสดงข้อผิดพลาด: "บรรทัด
‹line›ไม่ใช่ส่วนหัวของ HTTP หรือบรรทัดสถานะที่ถูกต้อง" - หากชื่อส่วนหัวไม่ถูกต้อง จะแสดงข้อผิดพลาด: "บรรทัด
‹line›มีชื่อส่วนหัว HTTP ที่ไม่ถูกต้อง"
- ต้นทางคําขอ: ระบุรูปแบบ (Scheme) โฮสต์ (Host) และพอร์ตเสริม (Port) เช่น
https://app.example.comห้ามใส่เส้นทาง URL (Path), คิวรี (Query) หรือข้อมูลประจำตัวเด็ดขาด หากไม่ถูกต้องจะแสดงข้อผิดพลาด: "ป้อนต้นทางที่มีเฉพาะรูปแบบ โฮสต์ และพอร์ตเสริม เช่น https://app.example.com" - วิธีการที่ร้องขอ: ระบุโทเค็นวิธีการ HTTP (HTTP Method) หากไม่ถูกต้องจะแสดงข้อผิดพลาด: "ป้อนโทเค็นวิธีการ HTTP ที่ถูกต้อง" หรือหากเป็นวิธีที่ต้องห้ามจะแสดง: "เบราว์เซอร์ไม่อนุญาตให้ใช้วิธีการ
‹method›ในคําขอดึงข้อมูล" - ชื่อส่วนหัวที่ร้องขอ: ระบุชื่อส่วนหัวจาก
Access-Control-Request-Headersโดยคั่นด้วยเครื่องหมายจุลภาคหรือขึ้นบรรทัดใหม่ หากไม่ถูกต้องจะแสดงข้อผิดพลาด: ""‹header›" ไม่ใช่ชื่อส่วนหัวของคําขอ HTTP ที่ถูกต้อง" - รวมข้อมูลประจําตัว: สวิตช์เปิด/ปิดเพื่อระบุว่าคำขอนี้มีการส่งคุกกี้หรือการตรวจสอบสิทธิ์แบบ HTTP Authentication หรือไม่
หากมีข้อมูลนำเข้าส่วนใดไม่ถูกต้อง ระบบจะแสดงข้อความเตือนทั่วไปว่า "แก้ไขอินพุตที่ไฮไลต์แล้วลองอีกครั้ง"
การวิเคราะห์ผลลัพธ์และการตัดสินใจของเบราว์เซอร์
เมื่อกดปุ่มตรวจสอบ เครื่องมือจะแสดงสถานะการตัดสินใจของเบราว์เซอร์ ด้วยข้อความใดข้อความหนึ่งดังต่อไปนี้:
- "วางการตอบกลับเพื่อตรวจสอบนโยบาย CORS" (สถานะเริ่มต้นก่อนป้อนข้อมูล)
- "ป้อนรายละเอียดการตอบกลับและคําขอ จากนั้นตรวจสอบนโยบาย CORS" (เมื่อไม่มีข้อมูลนำเข้า)
- "อนุญาตโดยการตอบกลับ CORS ที่วางไว้"
- "ถูกบล็อกโดยการตอบกลับ CORS ที่วางไว้"
- "ส่วนหัวผ่านเกณฑ์ แต่ไม่ทราบสถานะของพรีไฟลต์"
นอกจากนี้ ระบบจะแสดง "เขตข้อมูล Access-Control ที่แยกวิเคราะห์" พร้อมระบุเหตุผลประกอบการตัดสินใจอย่างละเอียด
กฎเกณฑ์และกรณีเฉพาะในการตรวจสอบ CORS
การประเมินผลของเครื่องมืออ้างอิงตามข้อกำหนดมาตรฐานของ CORS ซึ่งมีกฎและกรณีขอบเขต (Edge Cases) ที่สำคัญดังนี้:
ข้อกำหนดเกี่ยวกับข้อมูลประจำตัว (Credentials)
เมื่อมีการเลือก "รวมข้อมูลประจําตัว":
- ส่วนหัว
Access-Control-Allow-Originจะไม่สามารถใช้เครื่องหมายไวลด์การ์ด*ได้ หากใช้จะแสดงเหตุผล: "Access-Control-Allow-Origin ไม่สามารถเป็น * เมื่อรวมข้อมูลประจําตัว" - ค่าของ
Access-Control-Allow-Credentialsจะต้องเป็นtrueเท่านั้น หากไม่มีจะแสดงเหตุผล: "คําขอที่ได้รับการรับรองต้องมี Access-Control-Allow-Credentials: true" - เครื่องหมายไวลด์การ์ด
*ในส่วนหัวAccess-Control-Allow-MethodsและAccess-Control-Allow-Headersจะสูญเสียคุณสมบัติการเป็นไวลด์การ์ดทันที
การจัดการเครื่องหมายไวลด์การ์ดและส่วนหัว Authorization
- หากไม่มีการรวมข้อมูลประจำตัว เครื่องหมาย
*จะสามารถใช้ในAccess-Control-Allow-MethodsและAccess-Control-Allow-Headersได้ - อย่างไรก็ตาม ส่วนหัว
Authorizationถือเป็นกรณีพิเศษ ซึ่งจะต้องระบุชื่อส่วนหัวนี้ไว้ในAccess-Control-Allow-Headersอย่างชัดเจนเท่านั้น การใช้Access-Control-Allow-Headers: *จะไม่ครอบคลุมส่วนหัวนี้ หากตรวจพบจะแสดงเหตุผล: "Authorization ต้องระบุไว้อย่างชัดเจน Access-Control-Allow-Headers: * ไม่ครอบคลุม"
ความสำคัญของสถานะ HTTP ในการตอบกลับพรีไฟลต์
- การตอบกลับพรีไฟลต์ (Preflight Response) จำเป็นต้องมีสถานะ HTTP ในกลุ่ม 2xx (เช่น 200 หรือ 204) จึงจะถือว่าสำเร็จ
- หากไม่มีการวางบรรทัดสถานะ HTTP ในข้อมูลนำเข้า เครื่องมือจะไม่สามารถตรวจสอบสถานะพรีไฟลต์ได้ และจะแสดงเหตุผลว่า "ไม่ได้วางบรรทัดสถานะ HTTP จึงตรวจสอบสถานะพรีไฟลต์ 2xx ที่จำเป็นไม่ได้" ส่งผลให้ผลลัพธ์การตัดสินใจกลายเป็น "ส่วนหัวผ่านเกณฑ์ แต่ไม่ทราบสถานะของพรีไฟลต์"
คำถามที่พบบ่อย (FAQ)
ควรวางการตอบกลับจริงหรือการตอบกลับพรีไฟลต์? : ใช้การตอบกลับจริงเพื่อตรวจสอบว่าโค้ดในเบราว์เซอร์อ่านการตอบกลับนั้นได้หรือไม่ ใช้การตอบกลับพรีไฟลต์สำหรับการตอบ OPTIONS ที่อนุญาตวิธีและชื่อส่วนหัวของคำขอที่จะส่งในภายหลัง
เหตุใดสัญลักษณ์ตัวแทนจึงล้มเหลวด้วยข้อมูลประจําตัว? : เมื่อรวมคุกกี้หรือการรับรองความถูกต้องของ HTTP ต้นทางที่อนุญาตจะต้องตรงกับต้นทางที่ร้องขอทุกประการ ไวลด์การ์ดสําหรับวิธีการและส่วนหัวที่อนุญาตจะสูญเสียความหมายของไวลด์การ์ดเช่นกัน
ผลลัพธ์ที่ผ่านพิสูจน์ได้ว่าคําขอสดจะใช้งานได้หรือไม่? : ไม่ ผลลัพธ์นี้ครอบคลุมเฉพาะการตอบกลับที่วางและรายละเอียดคำขอที่ป้อนที่นี่เท่านั้น การเปลี่ยนเส้นทาง การตอบกลับที่แคชไว้ การเปลี่ยนกฎของเซิร์ฟเวอร์ ส่วนขยายเบราว์เซอร์ และการตอบกลับจริงหลังพรีไฟลต์ยังอาจทำให้ผลลัพธ์เปลี่ยนไปได้