เครือข่าย/HTTP

CORS Checker / Explainer

อธิบายทีละขั้นตอนว่าเบราว์เซอร์จะอนุญาตคำขอข้ามโดเมน (cross-origin) หรือไม่ — การจัดประเภท simple/preflight การตรวจสอบส่วนหัว Access-Control-* ของการตอบกลับ สรุปผล

Credentials (fetch)

บรรทัดละหนึ่งรายการ "ชื่อ" หรือ "ชื่อ: ค่า" — ค่าไม่มีผลต่อการจัดประเภท

นำมาจากแท็บ 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

Common uses

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

บทความ: เครือข่าย/HTTP

การแยกส่วน URL: ที่อยู่เว็บประกอบด้วยส่วนใดบ้าง

ส่วนแฟรกเมนต์ของ URL (หลัง #) ไม่เคยถูกส่งไปยังเซิร์ฟเวอร์เลย มีแต่เบราว์เซอร์เท่านั้นที่ประมวลผล

คิวรีสตริงกับ JSON: อะไรเหมาะกว่าสำหรับส่งข้อมูลที่ซับซ้อน

เหตุใดจึงไม่มีวิธีมาตรฐานสำหรับการส่งอาร์เรย์ผ่านคิวรีสตริง

User-Agent: เหตุใด Chrome ถึงมีคำว่า "Mozilla" และ "Safari"

เหตุใด User-Agent ของ Chrome จึงอ้างตัวว่าเป็น "Mozilla" และ "Safari" ทั้งที่ไม่ใช่

HTTP Basic Auth: เฮดเดอร์ Authorization ถูกสร้างขึ้นอย่างไร

Base64 ไม่ใช่การเข้ารหัส — รหัสผ่านของ Basic Auth สามารถถูกถอดรหัสได้ในไม่กี่วินาที

HTTP Headers: เมทาดาต้าที่มาพร้อมกับทุกคำขอและการตอบกลับ

เฮดเดอร์ Content-Type บอกเบราว์เซอร์อย่างไรว่าจะจัดการการตอบกลับเป็น HTML, JSON หรือรูปภาพ

คุกกี้: เหตุใดแอตทริบิวต์ Secure, HttpOnly และ SameSite จึงสำคัญ

เหตุใดแอตทริบิวต์ HttpOnly จึงช่วยป้องกันไม่ให้คุกกี้เซสชันถูกขโมยในการโจมตี XSS

Email Headers: SPF, DKIM และ DMARC ตรวจสอบผู้ส่งจริงอย่างไร

เหตุใดต้องอ่านเฮดเดอร์ Received จากล่างขึ้นบนเพื่อติดตามเส้นทางจริงของอีเมล