เริ่มจากแยกเหตุการณ์ที่เข้ามาไม่ถึง กับเหตุการณ์ที่ถูกปฏิเสธ
หลังเปลี่ยนผู้ให้บริการหรือย้าย Webhook Endpoint ทีมมักเห็นยอดรายการไม่เข้าแล้วสรุปว่า API ล่ม ทั้งที่อาจเป็นคนละอาการ: ผู้ส่งไม่เรียก URL, ผู้ส่งเรียกแล้วเครือข่ายตอบผิด, หรือคำขอถึงระบบแต่ตัวตรวจลายเซ็นไม่ยอมรับ ต้องแยกสามชั้นนี้ก่อนแก้ Secret เพราะการเปลี่ยนค่าลับแบบสุ่มอาจทำให้เหตุการณ์ที่เคยผ่านถูกปฏิเสธเพิ่มขึ้น เริ่มจากเวลาเหตุการณ์ รหัสการส่งจากผู้ให้บริการ HTTP status และผลการตรวจ Signature โดยไม่เก็บเนื้อหาลูกค้าหรือค่าลับลง Log ถ้าไม่มีหลักฐานการส่ง อย่าเพิ่งกล่าวโทษขั้นตอนตรวจลายเซ็น
ตารางวินิจฉัยที่ควรใช้ก่อนแก้โค้ด
| อาการ | หลักฐานที่ต้องดู | สิ่งที่ควรทำ |
|---|---|---|
| ไม่มีคำขอเข้า | Delivery history และ URL ปลายทาง | ตรวจ DNS, route, firewall และการสมัคร Event |
| คำขอเข้าแต่ 401/403 | Signature header, secret version, raw body | ตรวจสูตรและกุญแจที่ถูกต้อง |
| ตรวจผ่านแต่ไม่เกิดงาน | Event type, queue, idempotency state | ตรวจ consumer โดยไม่ปิดการตรวจ Signature |
| เกิดงานซ้ำหลังแก้ | Delivery ID และสถานะงานเดิม | กันการทำซ้ำก่อน replay |
ตารางนี้เป็นแบบตรวจสอบเชิงปฏิบัติ ไม่ใช่ผลการทดสอบระบบใดจริง ผู้รับผิดชอบควรบันทึกผลที่พบแยกจากข้อสันนิษฐาน และห้ามใส่ Secret ลงช่องหลักฐานแม้จะเป็นเอกสารภายในก็ตาม
Signature ยืนยันอะไร และไม่ยืนยันอะไร
ลายเซ็น Webhook ใช้ตรวจความถูกต้องของข้อความตามวิธีที่ผู้ให้บริการกำหนดและกุญแจที่ตกลงกัน เช่น GitHub ใช้ HMAC-SHA256 กับ payload และส่งผลใน X-Hub-Signature-256 แต่แต่ละแพลตฟอร์มมีชื่อ Header รูปแบบสตริงที่นำไปเซ็น และนโยบายเวลาต่างกัน การตรวจผ่านไม่ได้หมายความว่าเหตุการณ์ยังใหม่ ไม่เคยถูกส่งซ้ำ หรือข้อมูลธุรกิจถูกต้องเสมอ ต้องตรวจสิทธิ์ของ Event, เวลา, ตัวระบุเหตุการณ์ และสถานะการประมวลผลแยกต่างหาก ไม่ควรใช้การรู้ URL เป็นหลักฐานว่าใครก็ส่งข้อมูลได้
ก่อนหมุน Secret ให้ทำแผนที่ของเก่าและของใหม่
ทำทะเบียนหนึ่งแถวต่อ Endpoint โดยมีชื่อผู้ให้บริการ สภาพแวดล้อม Production หรือ Test URL ปลายทาง ชื่อ Header สูตรการตรวจ รุ่น Secret ที่ใช้อยู่ เจ้าของการเปลี่ยน และเวลาที่จะปิดรุ่นเก่า ระบุด้วยว่า Secret ที่ได้จาก CLI ทดสอบอาจไม่ใช่ Secret ของ Endpoint จริง ตัวอย่างเช่นเอกสาร Stripe เตือนเรื่องการใช้ Endpoint Secret คนละตัวกับการทดสอบผ่าน CLI ให้ตรวจคู่มือผู้ให้บริการที่ใช้งานจริง ไม่คัดลอกวิธีของอีกระบบมาใช้ทั้งชุด หากทีมไม่รู้ว่า Secret ตัวไหนเป็นของ Endpoint ไหน ให้ HOLD การหมุนก่อนจนกว่าจะตรวจทะเบียนครบ
ลำดับการเปลี่ยนที่ปลอดภัยกว่าการสลับทีเดียว
- บันทึกการตั้งค่าปัจจุบันและผลตรวจที่ผ่านด้วยข้อมูลทดสอบ
- เตรียม Secret ใหม่ใน Secret Manager โดยจำกัดสิทธิ์ผู้เห็น
- ตรวจว่าผู้ให้บริการรองรับช่วงทับซ้อนของ Secret เก่าและใหม่หรือไม่
- ทดสอบ Endpoint ใหม่กับ Payload ที่เซ็นด้วย Secret ใหม่
- เปลี่ยนผู้ส่งตามขั้นตอนทางการ และเฝ้าดูอัตราปฏิเสธ
- ปิด Secret เก่าเมื่อมีหลักฐานว่าไม่มี Delivery ที่ยังต้องใช้
หากผู้ให้บริการไม่รองรับ Secret ซ้อนกัน อย่าสมมติว่าตั้งสองกุญแจในฝั่งรับแล้วผู้ส่งจะใช้ได้เอง ต้องวางหน้าต่างเปลี่ยนระบบและแผนจัดการเหตุการณ์ค้างตามข้อจำกัดจริง การหมุน Secret เป็นการเปลี่ยนข้อตกลงระหว่างผู้ส่งและผู้รับ ไม่ใช่แค่แก้ตัวแปร ENV หนึ่งบรรทัด
จุดที่พลาดบ่อยที่สุดคือการใช้ Body ที่ถูกแก้แล้ว
ลายเซ็นมักคำนวณจาก Raw Request Body ที่ได้รับจริง ไม่ใช่ JSON ที่ Parse แล้ว Serialize ใหม่ การจัดลำดับ Key ช่องว่าง เครื่องหมายขึ้นบรรทัด หรือการเข้ารหัสภาษาไทยอาจเปลี่ยน Byte จนตรวจไม่ผ่าน Stripe ระบุให้ใช้ Raw Body เดิม และ GitHub เตือนให้ระวัง Proxy ที่แก้ Payload ก่อนตรวจ ดังนั้นเส้นทาง Webhook ควรเก็บ Raw Bytes ก่อน Middleware ที่แปลง JSON และส่งต่อไปยังตัวตรวจตามสเปกของผู้ให้บริการ ห้ามแก้ด้วยการตัดช่องว่างจากทั้งสองฝั่งหรือปิดการตรวจลายเซ็นชั่วคราวใน Production
แยก Test กับ Production อย่างเข้มงวด
ข้อผิดพลาดอีกแบบคือระบบรับ Production แต่โหลด Secret จาก Test หรือมีการตั้งค่าเดียวกันครอบหลาย Endpoint เมื่อทดสอบสำเร็จในเครื่องแล้วจึงเข้าใจว่า Production พร้อม ทั้งที่ Header, Secret และเส้นทาง Network ไม่เหมือนกัน ให้ใช้ชื่อ Environment ชัดเจนและทดสอบการตั้งค่าโดยไม่แสดงค่าลับ เช่น แสดงชื่อ Key Alias และสถานะว่าพร้อมใช้งาน แทนการพิมพ์ Secret ใน Log การหมุนต้องมีผู้ตรวจสอบคนละบทบาทกับผู้เปลี่ยนค่าในระบบที่มีผลต่อธุรกรรมสำคัญ
ตรวจ Signature ก่อน Parse หรือก่อนเกิด Side Effect
เมื่อคำขอเข้า ให้จำกัดขนาด Body ตรวจ Header ที่จำเป็นและคำนวณ Signature ตามข้อกำหนด แล้วจึง Parse และตรวจ Event Type หลังยืนยันตัวผู้ส่ง หาก Signature ไม่ผ่านต้องไม่สร้าง Lead ไม่ส่งข้อความ ไม่เปลี่ยนสถานะคำสั่งซื้อ และไม่ยิง Automation ต่อ แม้ข้อมูลภายใน JSON จะดูสมเหตุสมผลก็ตาม การตรวจเทียบค่า Signature ควรใช้ฟังก์ชันเปรียบเทียบที่ลดความเสี่ยงด้านเวลา เช่น hash_equals ใน PHP เมื่อเหมาะกับรูปแบบที่ตรวจได้ และต้องตรวจรูปแบบ Header ก่อนเปรียบเทียบด้วย
Replay Protection ไม่ใช่เรื่องเดียวกับ Signature
บางผู้ให้บริการเซ็นข้อมูลพร้อม Timestamp เพื่อช่วยจำกัดการนำคำขอเก่ากลับมาใช้ ขณะที่บางรายไม่ได้มีระบบเวลาภายในลายเซ็นแบบเดียวกัน อย่าสร้างหน้าต่างเวลาแบบเดาสุ่มแล้วอ้างว่าเป็นข้อกำหนดของผู้ให้บริการ หากไม่มี Timestamp ที่ตรวจได้ ให้พึ่ง Delivery ID หรือ Event ID กับสถานะการประมวลผลตามสัญญาของระบบนั้น ส่วนการส่งซ้ำจากผู้ให้บริการเป็นพฤติกรรมปกติที่อาจเกิดได้ การตรวจลายเซ็นผ่านทุกครั้งก็ยังต้องมี Idempotency สำหรับงานที่ส่งข้อความหรือสร้างรายการ เพื่อไม่ให้ Retry กลายเป็นผลกระทบซ้ำ
ตัวอย่างสมมติ: ย้าย Endpoint แล้วคำขอที่ถูกต้องถูกปฏิเสธ
สมมติทีมย้ายตัวรับจากเซิร์ฟเวอร์เดิมไปยัง Framework ใหม่ โดยเพิ่ม JSON Middleware ก่อน Route Webhook ผู้ให้บริการยังส่ง Signature และ Payload เหมือนเดิม แต่ Framework แปลง JSON เป็น Object ก่อนนำกลับไปสร้างสตริงตรวจ ทำให้ลายเซ็นไม่ตรง ทีมไม่ควรเปลี่ยน Secret เพื่อกลบอาการนี้ วิธีพิสูจน์คือใช้ Payload ทดสอบที่รู้ค่า Signature ล่วงหน้า เทียบผลคำนวณจาก Raw Bytes กับค่าที่ผ่าน Middleware และตรวจว่าระบบใช้ Header ถูกชื่อ ตัวอย่างนี้สร้างเพื่ออธิบายการวินิจฉัย ไม่ใช่เหตุการณ์ลูกค้าจริง
แผนจัดการเหตุการณ์ค้างหลังการเปลี่ยน
ระหว่างการหมุน Secret อาจมี Delivery ที่ถูกปฏิเสธหรือยังอยู่ในคิวของผู้ให้บริการ อย่า Replay ทั้งหมดโดยไม่ดูว่าเหตุการณ์ใดถูกทำไปแล้ว เริ่มจากรายการ Delivery ที่ล้มเหลว แยกตาม Endpoint และช่วงเวลา ตรวจ Event ID กับสถานะงานในระบบปลายทาง แล้ว Replay เฉพาะเหตุที่ยังไม่ได้ทำตามวิธีของผู้ให้บริการ หากไม่แน่ใจว่าธุรกรรมเกิดขึ้นแล้วหรือไม่ ให้ส่งเข้าคิวตรวจโดยคน ไม่ควรส่งซ้ำอัตโนมัติเพื่อให้ Dashboard กลับเป็นสีเขียว
เกณฑ์ตรวจรับแบบ Positive และ Negative
| กรณีทดสอบ | ผลที่คาดหวัง |
|---|---|
| Payload และ Secret ถูกต้อง | ผ่าน Signature และเข้าคิวงานหนึ่งครั้ง |
| Body ถูกเปลี่ยนหนึ่ง Byte | ปฏิเสธก่อน Side Effect |
| ใช้ Secret ของ Test ใน Production | ปฏิเสธและแจ้งเตือนโดยไม่เปิดเผยค่า |
| ไม่มี Header หรือ Header ผิดรูปแบบ | ปฏิเสธอย่างปลอดภัย |
| ส่ง Delivery เดิมซ้ำ | ไม่เกิดผลธุรกิจซ้ำ |
เพิ่มกรณี Payload ภาษาไทย, Proxy, Timeout และการกู้คืนหลัง Secret เปลี่ยนตามสภาพแวดล้อมจริง ผลตรวจรับควรมีเวลา ผู้ทดสอบ รุ่นการตั้งค่า และหลักฐานที่ไม่เปิดเผยข้อมูลส่วนบุคคล
ใครต้องตัดสินใจเมื่อผลทดสอบไม่ผ่าน
ฝ่ายเทคนิคเป็นเจ้าของการตรวจ Signature และ Raw Body แต่ฝ่ายธุรกิจเป็นเจ้าของผลกระทบจากรายการที่ยังไม่เข้า เช่น ลูกค้ายังไม่ได้รับแจ้งหรือสถานะชำระเงินไม่เปลี่ยน ต้องมีผู้รับผิดชอบทั้งสองด้าน เมื่อพบ Signature Failure เพิ่มขึ้นหลังเปลี่ยนให้หยุดขยายการใช้งาน ไม่ปิด Security Check เพื่อให้ตัวเลขกลับมาปกติ การย้อนกลับต้องคำนึงถึง Secret และการตั้งค่าของผู้ส่งด้วย ไม่ใช่ย้อนเฉพาะโค้ดฝั่งรับ และต้องตรวจข้อมูลค้างหลังย้อนกลับทุกครั้ง
ลิงก์ความรู้ที่ใช้ร่วมกับงานนี้
ก่อนย้าย Endpoint ควรกลับไปทบทวน การเตรียมข้อมูลและสิทธิ์ก่อนเชื่อม API หากต้องออกแบบหลักฐานตรวจสอบหลังเหตุการณ์ อ่าน แนวทางเก็บ Audit Log ของ Automation และเมื่อกำหนดคนอนุมัติการกู้คืน ให้ใช้ แนวทาง Human Approval สำหรับ AI Workflow ประกอบ การวางระบบเชื่อมต่อสำหรับงานธุรกิจหลายขั้นตอนสามารถศึกษาขอบเขต บริการ AI Automation โดยไม่จำเป็นต้องเปิดใช้งานอัตโนมัติทุกขั้นทันที
สรุปแบบตัดสินใจ
ถ้าไม่พบคำขอให้ตรวจ Delivery และเส้นทางเครือข่ายก่อน ถ้าคำขอถึงแต่ Signature ไม่ผ่านให้ตรวจ Secret รุ่นที่ถูกต้อง Header และ Raw Body ถ้าตรวจผ่านแต่ธุรกิจไม่เกิดผลให้ตรวจ Queue, Event Type และ Idempotency แยกกัน การหมุน Secret ที่ปลอดภัยต้องมี Baseline ขั้นตอนเปลี่ยน ผู้รับผิดชอบ ผลทดสอบทั้งกรณีผ่านและไม่ผ่าน รวมถึงแผนกู้เหตุการณ์ค้าง การรักษาลายเซ็นไม่ใช่ภาระส่วนเกิน แต่เป็นเงื่อนไขให้ระบบอัตโนมัติทำงานกับข้อมูลที่เชื่อถือได้
คำถามที่พบบ่อย
เปลี่ยน Webhook Secret แล้วควรปิดการตรวจ Signature ชั่วคราวไหม?
ไม่ควร เพราะทำให้ผู้ส่งที่ไม่ได้รับอนุญาตเรียกงานได้ ควรแก้การตั้งค่า Secret และ Raw Body ในสภาพแวดล้อมทดสอบ แล้วค่อยเปลี่ยน Production ตามแผน
ทำไม Test ผ่านแต่ Production ตรวจ Signature ไม่ผ่าน?
อาจใช้ Secret คนละ Endpoint มี Middleware แปลง Body หรือ Header ไม่เหมือนกัน ต้องตรวจรุ่นการตั้งค่าและ Raw Bytes โดยไม่พิมพ์ค่าลับ
ถ้า Webhook ส่งเหตุการณ์ซ้ำหลังแก้ Signature ต้องทำอย่างไร?
ตรวจ Event ID และสถานะ Side Effect ก่อน Replay ให้ Idempotency ป้องกันการสร้างรายการหรือส่งข้อความซ้ำ ไม่ถือว่า Signature ผ่านแล้วแปลว่ายังไม่เคยประมวลผล
ผู้ให้บริการทุกเจ้าหมุน Secret แบบใช้สองกุญแจพร้อมกันได้หรือไม่?
ไม่ได้เสมอไป ต้องตรวจเอกสารของผู้ให้บริการแต่ละรายและกำหนดช่วงเปลี่ยนกับแผนรับเหตุการณ์ค้างตามข้อจำกัดจริง
แหล่งอ้างอิง
คำถามที่พบบ่อยเกี่ยวกับ Webhook Signature ไม่ผ่านหลังย้ายระบบ
เปลี่ยน Webhook Secret แล้วควรปิดการตรวจ Signature ชั่วคราวไหม?
ไม่ควร เพราะทำให้ผู้ส่งที่ไม่ได้รับอนุญาตเรียกงานได้ ควรแก้การตั้งค่า Secret และ Raw Body ในสภาพแวดล้อมทดสอบ แล้วค่อยเปลี่ยน Production ตามแผน
ทำไม Test ผ่านแต่ Production ตรวจ Signature ไม่ผ่าน?
อาจใช้ Secret คนละ Endpoint มี Middleware แปลง Body หรือ Header ไม่เหมือนกัน ต้องตรวจรุ่นการตั้งค่าและ Raw Bytes โดยไม่พิมพ์ค่าลับ
ถ้า Webhook ส่งเหตุการณ์ซ้ำหลังแก้ Signature ต้องทำอย่างไร?
ตรวจ Event ID และสถานะ Side Effect ก่อน Replay ให้ Idempotency ป้องกันการสร้างรายการหรือส่งข้อความซ้ำ ไม่ถือว่า Signature ผ่านแล้วแปลว่ายังไม่เคยประมวลผล
ผู้ให้บริการทุกเจ้าหมุน Secret แบบใช้สองกุญแจพร้อมกันได้หรือไม่?
ไม่ได้เสมอไป ต้องตรวจเอกสารของผู้ให้บริการแต่ละรายและกำหนดช่วงเปลี่ยนกับแผนรับเหตุการณ์ค้างตามข้อจำกัดจริง
ดูขอบเขตบริการที่เกี่ยวข้อง วิธีทำงาน และข้อมูลที่ควรเตรียมก่อนให้ทีมประเมิน
ดูบริการที่เกี่ยวข้องส่งรายละเอียดงานให้ทีมประเมิน
กรอกชื่อ เบอร์โทร และรายละเอียดที่อยากให้ช่วย ทีมจะติดต่อกลับเพื่อประเมินแนวทาง