เครือข่าย/HTTP
CORS Checker / Explainer
อธิบายทีละขั้นตอนว่าเบราว์เซอร์จะอนุญาตคำขอข้ามโดเมน (cross-origin) หรือไม่ — การจัดประเภท simple/preflight การตรวจสอบส่วนหัว Access-Control-* ของการตอบกลับ สรุปผล
บรรทัดละหนึ่งรายการ "ชื่อ" หรือ "ชื่อ: ค่า" — ค่าไม่มีผลต่อการจัดประเภท
นำมาจากแท็บ Network ใน DevTools (ส่วนหัวของการตอบกลับเองหรือของ preflight OPTIONS) หรือจาก curl -I
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
บทความเกี่ยวกับเครื่องมือนี้: ข้อผิดพลาด CORS: เหตุใดเบราว์เซอร์จึงบล็อกการตอบกลับ
คำถามที่พบบ่อย
ทำไมคำขอถึงล้มเหลวด้วย CORS error ทั้งที่เซิร์ฟเวอร์ตอบกลับสำเร็จ?
CORS ถูกบังคับใช้โดยเบราว์เซอร์ ไม่ใช่เซิร์ฟเวอร์ — หากการตอบกลับขาดเฮดเดอร์ Access-Control-Allow-Origin ที่ตรงกับ origin ของคำขอ เบราว์เซอร์จะบล็อก JavaScript ไม่ให้อ่านการตอบกลับ แม้ว่าคำขอเองจะสำเร็จแล้ว
คำขอแบบธรรมดากับคำขอแบบ preflight ต่างกันอย่างไร?
คำขอแบบธรรมดา (GET/POST พื้นฐานพร้อมเฮดเดอร์มาตรฐาน) ผ่านไปโดยตรง ในขณะที่คำขอที่มีเฮดเดอร์กำหนดเอง วิธีอื่น หรือประเภทเนื้อหาบางอย่างจะกระตุ้นคำขอ preflight OPTIONS ก่อนเพื่อตรวจสอบสิทธิ์ก่อนส่งคำขอจริง
การตรวจสอบเฮดเดอร์ CORS ที่นี่ส่งข้อมูลของฉันไปยังเซิร์ฟเวอร์หรือไม่?
เครื่องมือนี้ตรวจสอบเฮดเดอร์ที่คุณให้มาหรือดึงมาจากเบราว์เซอร์ของคุณโดยตรง ไม่มีเซิร์ฟเวอร์ตัวกลางใดเก็บข้อมูลคำขอของคุณ
CORS ปกป้อง API จากคำขอที่เป็นอันตรายหรือไม่?
ไม่ CORS จำกัดแค่สิ่งที่ JavaScript ในเบราว์เซอร์อ่านได้เท่านั้น — ผู้โจมตีที่ใช้ curl, Postman หรือสคริปต์แบ็กเอนด์จะข้ามมันไปได้ทั้งหมด ดังนั้นการยืนยันตัวตนและการให้สิทธิ์ที่แท้จริงต้องนำไปใช้บนเซิร์ฟเวอร์
ทำไม Access-Control-Allow-Origin: * ถึงใช้ร่วมกับ credentials: include ไม่ได้?
ข้อกำหนดห้ามการรวมกันนี้อย่างตั้งใจด้วยเหตุผลด้านความปลอดภัย: การอนุญาต credentials (คุกกี้ เฮดเดอร์การให้สิทธิ์) ร่วมกับสัญลักษณ์ตัวแทนที่ยอมรับ origin ใดก็ได้จะเป็นช่องโหว่ด้านความปลอดภัยที่ร้ายแรง ดังนั้นเซิร์ฟเวอร์ต้องส่งคืน origin ที่ระบุเจาะจงเมื่อใช้ credentials