จำลอง preflight และคำขอจริงจากฝั่งเซิร์ฟเวอร์ ระบุปัญหาได้อย่างรวดเร็วว่าเกิดจาก Allow-Origin, Allow-Headers หรือ credentials
จำลอง CORS preflight และคำขอจริงจากเซิร์ฟเวอร์ ตรวจสอบส่วนหัวหลัก 6 รายการ ค้นหาข้อผิดพลาดการตั้งค่าข้ามโดเมนอย่างแม่นยำ พร้อมตัวอย่างโค้ด Nginx/Node.js/Spring
นี่คือปัญหา CORS ที่คลาสสิกที่สุด! เพราะ Postman และ curl ไม่ได้รับผลกระทบจากนโยบายต้นทางเดียวกันเลย — พวกมันคือไคลเอ็นต์ HTTP ไม่ใช่เบราว์เซอร์ ไม่บล็อกการตอบสนอง และไม่ส่ง OPTIONS preflight อัตโนมัติ ข้อผิดพลาดข้ามโดเมนเป็นกลไกความปลอดภัยเฉพาะของเบราว์เซอร์ เฉพาะสภาพแวดล้อม JavaScript ของเบราว์เซอร์เท่านั้นที่ตรวจสอบ CORS Postman เรียกสำเร็จพิสูจน์ได้แค่ว่าอินเทอร์เฟซส่งคืนข้อมูลได้ ไม่ได้พิสูจน์ว่า CORS ถูกต้อง คุณต้องใช้เบราว์เซอร์หรือเครื่องมือนี้ (จำลองกระบวนการ CORS ฝั่งเซิร์ฟเวอร์) ในการตรวจสอบ
99% ของข้อผิดพลาด CORS เป็นปัญหาการตั้งค่าแบ็กเอนด์ ฟรอนต์เอนด์สามารถทำได้น้อยมาก แก่นของ CORS คือเซิร์ฟเวอร์ให้สิทธิ์เบราว์เซอร์ผ่านส่วนหัว ฟรอนต์เอนด์สามารถตั้งค่า withCredentials ได้เท่านั้น ไม่สามารถหลีกเลี่ยงข้อจำกัดความปลอดภัยได้ การใช้พร็อกซีของฟรอนต์เอนด์เป็นการหลอกเบราว์เซอร์ให้คิดว่าเป็นต้นทางเดียวกัน ไม่ใช่การแก้ CORS อย่างแท้จริง สภาพแวดล้อมการผลิตยังต้องให้แบ็กเอนด์กำหนดค่า CORS ที่ถูกต้อง
เพราะ GET มักตรงตาม simple request เบราว์เซอร์ส่งโดยตรง; ส่วน POST หากส่ง Content-Type: application/json (90% ของอินเทอร์เฟซ POST) จะไม่เป็น simple request จะเรียก OPTIONS preflight คำขอ preflight ต้องการส่วนหัว CORS ที่ถูกต้อง หลายคนกำหนดส่วนหัวแค่ GET/POST แต่ไม่จัดการ OPTIONS วิธี PUT/DELETE/PATCH เองก็ไม่ใช่วิธีอย่างง่าย จำเป็นต้องเรียก preflight แน่นอน
สภาพแวดล้อมการพัฒนามีหลายวิธี: ①พร็อกซีในตัวของเฟรมเวิร์ก (devServer.proxy, server.proxy): พร็อกซีคำขอไปยังต้นทางเดียวกัน; ②ปิดพารามิเตอร์ความปลอดภัยของเบราว์เซอร์ด้วย --disable-web-security จำกัดสำหรับทดสอบในเครื่องเท่านั้น; ③แบ็กเอนด์กำหนดค่า CORS อนุญาต localhost (แนะนำ) สภาพแวดล้อมการผลิตจำเป็นต้องให้แบ็กเอนด์กำหนดค่า CORS ที่ถูกต้อง: whitelist, Allow-Methods/Allow-Headers/Allow-Credentials, Vary: Origin หรือใช้เกตเวย์/Nginx จัดการอย่างเป็นหนึ่งเดียว
ไม่ได้ ส่วนหัวนี้มีได้เพียงหนึ่งค่า ไม่ว่าจะเป็นแหล่งที่มาแบบเจาะจงหรือ * เบราว์เซอร์จะไม่ยอมรับหลายแหล่งที่มา วิธีที่ถูกต้องคือ: เซิร์ฟเวอร์ดูแลรักษา whitelist ทุกครั้งที่ได้รับคำขอให้อ่าน Origin ตรวจสอบว่าอยู่ใน whitelist หรือไม่ หากอยู่ให้ส่งคืน Access-Control-Allow-Origin เป็นค่า Origin นั้น พร้อม Vary: Origin อย่าพยายามส่งคืนส่วนหัวหลายตัวหรือคั่นด้วยจุลภาค
OPTIONS preflight ไม่จำเป็นต้องส่งคืนตรรกะทางธุรกิจและเนื้อหาใดๆ เพียงส่วนหัว CORS ที่ถูกต้องและ 200/204 ก็เพียงพอ แนวทางปฏิบัติที่ดีที่สุดคือ: ดัก OPTIONS ที่ Nginx/เกตเวย์โดยตรง ส่งคืน 204 No Content และส่วนหัว CORS ที่ถูกต้อง ไม่ต้องส่งต่อแบ็กเอนด์ ลดภาระและหลีกเลี่ยง 405 แต่ต้องตรวจสอบให้แน่ใจว่าส่วนหัว CORS ของ OPTIONS สอดคล้องกับคำขอจริง
คำขอข้ามโดเมนที่มี Cookie ต้องตรงตามสามเงื่อนไข: ①withCredentials=true หรือ credentials: 'include'; ②Allow-Credentials: true; ③Allow-Origin ต้องเป็นแหล่งที่มาแบบเจาะจง (ห้าม *) ขาดอย่างใดอย่างหนึ่งไม่ได้ นอกจากนี้ Cookie ต้องตั้งค่า SameSite=None; Secure (HTTPS) จึงจะส่งข้ามโดเมนได้; SameSite=Lax/Strict จะไม่นำมา; คุณสมบัติ Domain ต้องถูกต้อง; ยังต้องสังเกตนโยบาย Cookie ของบุคคลที่สาม
CORS คือการผ่อนปรนข้อจำกัดข้ามโดเมน CSRF คือการโจมตีปลอมแปลงคำขอข้ามไซต์ ทั้งสองเป็นแนวคิดที่แตกต่าง การกำหนดค่า CORS อย่างถูกต้องจะไม่ทำให้เกิด CSRF โดยตรง — CORS เพียงอนุญาตให้ JS อ่านการตอบสนอง ส่วน CSRF คือผู้โจมตีชักจูงผู้ใช้ส่งคำขอโดยไม่รู้ตัว คำขอเหล่านี้แม้ไม่มี CORS ก็จะถูกส่งไปพร้อม Cookie การป้องกัน CSRF ต้องใช้ CSRF Token, SameSite Cookie, ตรวจสอบ Origin/Referer อย่าป้องกัน CSRF ด้วยการปิด CORS แต่หาก Allow-Origin เป็น * และอนุญาต credentials จะขยายความเสี่ยง CSRF ดังนั้นเมื่อส่ง credentials ห้ามใช้ *
การโหลดทรัพยากรด้วย <img>, <script>, <link> ปกติจะไม่มีปัญหา CORS เป็น "ทรัพยากรที่ฝัง" ไม่ใช่ AJAX เบราว์เซอร์อนุญาตให้โหลดแต่ JS ไม่สามารถอ่านเนื้อหาได้ แต่หากต้องการใช้ Canvas จัดการรูปภาพข้ามโดเมนหรือใช้ fetch/XHR อ่านเนื้อหา จำเป็นต้องมี CORS และเพิ่มแอตทริบิวต์ crossorigin การดาวน์โหลดไฟล์ข้ามโดเมนไม่จำเป็นต้องมี CORS การเปลี่ยนเส้นทางจะส่งผลต่อ CORS: หาก OPTIONS ส่งคืน 3xx เบราว์เซอร์จะปฏิเสธโดยตรง (Preflight redirect not allowed)
ประเด็นสำคัญ: ①ใช้ map จับคู่ Origin whitelist ตั้งค่า $cors_origin แบบไดนามิก; ②OPTIONS ส่งคืน 204 โดยตรงไม่ต้องส่งต่อ; ③add_header ต้องเพิ่ม always เพื่อให้แน่ใจว่าการตอบสนองข้อผิดพลาดก็มีส่วนหัว; ④เพิ่ม Vary: Origin; ⑤กำหนดค่า Allow-Methods/Allow-Headers/Credentials อย่างถูกต้อง ตัวอย่างการตั้งค่าสามารถพบได้ในคำแนะนำการแก้ไขของเครื่องมือนี้ สำหรับ Nginx, Apache, Node.js Express, Spring Boot, Flask/Django, Koa, Go Gin เรามีตัวอย่างที่ผ่านการตรวจสอบแล้ว
ขั้นตอนการยืนยัน: ①ใช้เครื่องมือนี้ตรวจสอบออนไลน์ก่อน; ②เปิด DevTools Network ทำเครื่องหมาย Disable cache กระตุ้นคำขอ ตรวจสอบส่วนหัว OPTIONS และคำขอจริง; ③ดู Console ว่ามีข้อผิดพลาดหรือไม่; ④ทดสอบสถานการณ์ต่างๆ: GET ไม่มีส่วนหัว, POST แบบ application/json, PUT/DELETE, มี/ไม่มี Cookie, มีส่วนหัวที่กำหนดเอง; ⑤ใช้ curl จำลอง OPTIONS: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint
เบราว์เซอร์ต่างๆ มีความแตกต่างกันในรายละเอียด CORS: ①Safari จำกัด Max-Age เข้มงวดกว่า นโยบาย Cookie (ITP) ก็เข้มงวดกว่า; ②Chrome ตรวจสอบสัญลักษณ์แทนเมื่อส่ง credentials เข้มงวดกว่า ไม่อนุญาต *; ③IE11 ใช้ XDomainRequest แทน XMLHttpRequest มีข้อจำกัดมากมาย; ④การประมวลผล Vary, การเปลี่ยนเส้นทาง, ส่วนหัวความปลอดภัยมีความแตกต่างละเอียดอ่อน วิธีแก้คือกำหนดค่าตามข้อกำหนดอย่างเข้มงวด อย่าพึ่งพาพฤติกรรมของเบราว์เซอร์ใดเบราว์เซอร์หนึ่ง
แนะนำ 3600 (1 ชั่วโมง) ถึง 86400 (24 ชั่วโมง) สั้นเกินไป (60 วินาที): แคชหมดเร็ว ส่ง OPTIONS บ่อย เพิ่มเวลาและภาระเซิร์ฟเวอร์ ยาวเกินไป (หนึ่งปี): หลังอัปเดตการตั้งค่าแคชเก่าอาจอยู่นาน ทำให้การตั้งค่าใหม่ไม่ทำงาน Chrome/Firefox ตัดค่าเกิน 86400 ไว้ที่ 86400 โดยอัตโนมัติ สภาพแวดล้อมการพัฒนาสามารถตั้งค่าเป็น -1 ปิดแคชเพื่อความสะดวกในการดีบัก
WebSocket (ws:// และ wss://) ไม่ได้รับผลกระทบจากกลไก CORS ของ HTTP เพราะเป็นโปรโตคอลอิสระ แต่ระยะ handshake เป็นคำขอ HTTP เซิร์ฟเวอร์สามารถตรวจสอบ Origin เพื่อตัดสินใจอนุญาตการเชื่อมต่อ — นี่คือการควบคุมสิทธิ์ระดับ WebSocket ไม่ใช่ CORS มาตรฐาน แต่หลักการคล้ายกัน หาก WebSocket ถูกปฏิเสธ ต้องตรวจสอบการตั้งค่าการตรวจสอบ Origin ของเซิร์ฟเวอร์ WebSocket ไม่ใช่ส่วนหัว CORS ของ HTTP
เครื่องมือนี้จำลองกระบวนการ preflight และคำขอจริงตามข้อกำหนด W3C CORS อย่างเข้มงวดฝั่งเซิร์ฟเวอร์ ตรรกะสอดคล้องกับเบราว์เซอร์สมัยใหม่โดยพื้นฐาน หากเครื่องมือผ่านแต่เบราว์เซอร์ยังมีข้อผิดพลาด สาเหตุที่เป็นไปได้: ①เบราว์เซอร์แคชผลลัพธ์เก่า ลอง Ctrl+F5 รีเฟรชหรือล้างแคช; ②ส่วนขยายเบราว์เซอร์แก้ไขหรือบล็อกคำขอ; ③การตั้งค่าที่กรอกในเครื่องมือไม่สอดคล้องกับที่ฟรอนต์เอนด์ส่งจริง; ④แคชโหนด CDN/พร็อกซีไม่สอดคล้องกัน; ⑤เบราว์เซอร์มีนโยบายความปลอดภัยพิเศษ (เนื้อหาผสม, ข้อจำกัด file://)
