Softonic

เครื่องทดสอบ CORS

ขั้นตอน 1 / 3
ถัดไป

ข้อผิดพลาดของ CORS มักแสดงเป็นสีแดงตามมาตรฐานในคอนโซลเบราว์เซอร์ ซึ่งเกิดขึ้นเมื่อเบราว์เซอร์เข้าถึง API จากแหล่งที่มาต่างกัน และระบบจะบล็อกการตอบกลับ โปรแกรมทดสอบนี้จะส่งคำขอ preflight OPTIONS ไปยัง URL ใดๆ ที่คุณป้อน ด้วยต้นทางและวิธีการที่คุณเลือก จากนั้นจึงวิเคราะห์เฮดเดอร์ Access-Control-* เพื่อให้คุณทราบได้อย่างชัดเจนว่าเซิร์ฟเวอร์อนุญาตอะไร การบล็อกอะไร และเหตุผลที่เบราว์เซอร์แจ้งเตือนข้อผิดพลาดนั้นอย่างไร

วิธีทดสอบ CORS

  1. 1

    กรุณาป้อน URL เป้าหมาย

    จุดสิ้นสุดของ API ที่คุณต้องการเรียกใช้งานจากฝั่งฟรอนต์เอนด์ โปรดระบุสตริงคำขอและโปรโตคอลที่ใช้

  2. 2

    ตั้งค่าวิธีการและจุดเริ่มต้น

    GET/POST/PUT/DELETE/PATCH: ต้นทางสามารถเป็น URL ของเว็บไซต์คุณ หรือต้นทางใดก็ได้ที่คุณต้องการจำลอง

  3. 3

    ทำความเข้าใจ preflight

    โปรแกรมทดสอบจะส่งคำขอ OPTIONS ด้วยต้นทางและวิธีการที่คุณเลือกเสมอ พร้อมกับเฮดเดอร์ Access-Control-Request-Headers: Content-Type ซึ่งเป็น preflight เดียวกับที่เบราว์เซอร์ส่งก่อนคำขอ JSON

  4. 4

    ดำเนินการทดสอบ

    โปรแกรมทดสอบจะส่ง preflight และรายงานสถานะ HTTP พร้อมทั้งเฮดเดอร์การตอบกลับ CORS ได้แก่ Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials และ Max-Age

  5. 5

    แก้ไขการตั้งค่าที่ผิดพลาด

    รายงานจะระบุสิ่งที่ขาดหรือไม่ถูกต้อง เช่น การไม่มีข้อมูล Allow-Origin, หัวข้อที่ถูกห้ามใช้ หรือวิธีการที่ไม่อนุญาต

เฮดเดอร์ที่สำคัญ

เฮดเดอร์ ทำหน้าที่อะไร
Access-Control-Allow-Origin แหล่งที่มา (origin) ใดบ้างที่อ่านการตอบกลับได้
Access-Control-Allow-Methods Preflight: เมธอดใดบ้างที่อนุญาต
Access-Control-Allow-Headers Preflight: เฮดเดอร์คำขอใดบ้างที่อนุญาต
Access-Control-Allow-Credentials อนุญาตให้ใช้คุกกี้/การยืนยันตัวตนหรือไม่
Access-Control-Expose-Headers เฮดเดอร์การตอบกลับใดบ้างที่ JS อ่านได้
Access-Control-Max-Age ผลลัพธ์ของ preflight ถูกแคชไว้นานเท่าใด

คำขอแบบง่ายเทียบกับคำขอที่ต้องมี preflight

คำขอจะถือว่า “ง่าย” (ไม่ต้องมี preflight) ก็ต่อเมื่อ ทุกข้อ ต่อไปนี้เป็นจริงเท่านั้น:

  • เมธอดคือ GET, HEAD หรือ POST
  • เฮดเดอร์จำกัดอยู่เพียง Accept, Accept-Language, Content-Language และ Content-Type (ที่มีค่าเฉพาะ)
  • Content-Type หากมี จะเป็น application/x-www-form-urlencoded, multipart/form-data หรือ text/plain

สิ่งอื่นใดก็ตาม เช่น เนื้อหาแบบ JSON, เฮดเดอร์ Authorization, เฮดเดอร์ X-Foo ที่กำหนดเอง หรือเมธอด PUT/DELETE/PATCH จะกระตุ้นให้เกิด preflight OPTIONS เซิร์ฟเวอร์ต้องตอบ preflight ด้วยเฮดเดอร์ Allow-* ที่ถูกต้อง มิฉะนั้นคำขอจริงจะไม่ถูกส่งออกไปเลย

ข้อผิดพลาด CORS ที่พบบ่อย

  • “No Access-Control-Allow-Origin header” → เซิร์ฟเวอร์ไม่ได้ตั้งค่าเฮดเดอร์นี้ ให้แก้ไขที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่ฝั่งไคลเอนต์
  • “Credentials mode requires Allow-Origin not to be *” → หากคุณส่งคุกกี้ Allow-Origin ต้องเป็น origin ที่เฉพาะเจาะจง (หรือสะท้อนเฮดเดอร์ Origin กลับ)
  • “Request header X not allowed” → ให้เพิ่ม X เข้าไปใน Access-Control-Allow-Headers ในการตอบกลับ preflight
  • “Method not allowed” → ให้เพิ่มเมธอดนั้นเข้าไปใน Access-Control-Allow-Methods
  • “Redirect not allowed in preflight” → preflight ไม่สามารถติดตามการเปลี่ยนเส้นทางได้ ปลายทาง OPTIONS ต้องตอบกลับโดยตรง

Allow-Origin: * เทียบกับการสะท้อน Origin กลับ

Access-Control-Allow-Origin: * เป็นค่าที่อนุญาตการใช้งานได้ แต่ไม่สามารถรวมกับข้อมูลประจำตัว (credentials) ได้ ในสภาพแวดล้อมจริง ให้ส่งคืนข้อมูลแหล่งที่มาของคำขอ (Origin) กลับมา (หลังจากตรวจสอบความถูกต้องตามรายการอนุญาต: allowlist) และตั้งค่าเป็น Allow-Credentials: true หากจำเป็นต้องใช้คุกกี้

การใช้เซิร์ฟเวอร์ตัวกลางเป็นวิธีแก้ปัญหาชั่วคราว

หากคุณไม่สามารถควบคุมเซิร์ฟเวอร์ได้ พร็อกซีแบบบางบนโดเมนของคุณจะตัดการใช้งาน CORS ทั้งหมด โดยเบราว์เซอร์จะตรวจจับข้อมูลจากแหล่งเดียวกัน (same-origin) แทน แพลตฟอร์มโฮสติ้งหลายแห่ง เช่น Vercel, Netlify และ Cloudflare มีกฎการเขียนใหม่ (rewrite rules) ที่ออกแบบมาเพื่อจัดการเรื่องนี้โดยเฉพาะ

คำถามที่พบบ่อย

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

ยังอยู่ในขั้นตอนการพัฒนาเท่านั้น Chromium มีแฟลก --disable-web-security ซึ่งส่งผลกระทบต่อเว็บไซต์ทุกแห่งและอาจก่อให้เกิดความเสี่ยงได้ การแก้ไขที่ถูกต้องคือการใช้เฮดเดอร์ฝั่งเซิร์ฟเวอร์หรือใช้พร็อกซี

Postman ไม่ใช่เบราว์เซอร์, มันเพิกเฉยต่อ CORS อย่างสิ้นเชิง โดย CORS จะถูกบังคับใช้เฉพาะโดยเบราว์เซอร์สำหรับคำขอ JavaScript เท่านั้น ดังนั้น เซิร์ฟเวอร์ที่ทำงานภายใน Postman จึงไม่ได้มีการปรับให้รองรับ CORS อัตโนมัติ

ภาพและแท็กคลาสสิก <script> สามารถโหลดได้จากแหล่งที่มาต่างกันโดยไม่ต้องใช้ CORS แต่ JavaScript ไม่สามารถอ่านเนื้อหาภายในของแท็กเหล่านี้ได้ ส่วน <img crossorigin> และ fetch() จะบังคับใช้ CORS ดังนั้นภาพที่วาดบน canvas จึงกลายเป็น “ปนเปื้อน” (tainted) หากไม่มี CORS

เครื่องมือที่เกี่ยวข้อง

ทดสอบความเร็ว

ทดสอบความเร็วอินเทอร์เน็ตได้อย่างรวดเร็วและฟรีในเบราว์เซอร์ วัดความเร็วดาวน์โหลดเป็น Mbps พร้อมทั้งความหน่วงและจิตเตอร์ และดูว่าการเชื่อมต่อของคุณพร้อมสำหรับสตรีม 4K เล่นเกม และวิดีโอคอลหรือไม่ ไม่ต้องติดตั้งแอปและไม่ต้องสมัคร

เครื่องมือวิเคราะห์ส่วนหัวอีเมล

วิเคราะห์ส่วนหัวอีเมลดิบอย่างเป็นส่วนตัวในเบราว์เซอร์ ตรวจฮ็อป Received เวลา และข้อมูล SPF, DKIM, DMARC, ARC โดยไม่ต้องอัปโหลดข้อความ

ค้นหา DNS ย้อนกลับ

ค้นหาระเบียน PTR ของที่อยู่ IPv4 หรือ IPv6 เหมาะสำหรับตรวจแก้ปัญหาเซิร์ฟเวอร์อีเมล วิเคราะห์ log และตรวจสอบตัวกรองสแปม

IP ของฉันคืออะไร

ดูที่อยู่ IP ที่เซิร์ฟเวอร์นี้ได้รับสำหรับคำขอของคุณ ว่าเป็น IPv4 หรือ IPv6 และประเทศโดยประมาณเมื่อมีข้อมูล GeoIP ในเครื่อง.

ค้นหา WHOIS

ค้นหาข้อมูล WHOIS สาธารณะของโดเมน เช่น ผู้รับจดทะเบียน เนมเซิร์ฟเวอร์ รหัสสถานะ และวันหมดอายุ

การค้นหา DNS

ค้นหาระเบียน DNS A, AAAA, MX, TXT, NS, CNAME และ SOA ของโดเมนใดก็ได้โดยไม่ต้องเปิดเทอร์มินัล