เช็กลิสต์ HTTPS และ TLS สำหรับร้านค้าออนไลน์และ E-commerce: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

ร้านค้าออนไลน์ที่เปิด HTTPS ทั้งเว็บไซต์แล้วตั้งแต่วันแรก ยังพบเคสที่ลูกค้าเห็นคำเตือน \"ไม่ปลอดภัย\" ตอนกำลังจะกดจ่ายเงินอยู่บ่อยครั้ง สาเหตุมักไม่ใช่ตัวร้านหลัก แต่เป็นปลั๊กอินการตลาด วิดเจ็ตรีวิวสินค้า หรือสคริปต์ติดตามยอดขายที่แอดมินเพิ่มเข้ามาทีหลัง แล้วยังอ้างอิงไฟล์ผ่าน http:// อยู่

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

ทำไม HTTPS ในหน้าชำระเงินสำคัญกว่าหน้าอื่นของร้าน

เบราว์เซอร์สมัยใหม่ขึ้นป้ายเตือน \"ไม่ปลอดภัย\" ทันทีที่พบฟอร์มกรอกข้อมูลบนหน้าที่ไม่ใช่ HTTPS หรือพบ Mixed Content แบบ Active เช่นสคริปต์ที่โหลดผ่าน HTTP บนหน้าที่ควรเป็น HTTPS ทั้งหมด สำหรับร้านค้าทั่วไป คำเตือนนี้อาจแค่ทำให้ผู้ใช้ลังเล แต่สำหรับหน้าตะกร้าและหน้าชำระเงิน คำเตือนแบบนี้มักแปลว่าลูกค้าปิดแท็บทันทีและไม่กลับมาซื้ออีก

ปัญหาคือหน้าชำระเงินหลายร้านไม่ได้อยู่ในโดเมนหลักของร้าน แต่ Redirect ไปยังหน้าของผู้ให้บริการชำระเงินหรือฝัง iframe จากผู้ให้บริการภายนอก จุดต่อระหว่างสองระบบนี้เองที่มักหลุดการตรวจสอบ เพราะทีมร้านค้าคิดว่าเป็นความรับผิดชอบของผู้ให้บริการชำระเงินไปแล้ว

เช็กลิสต์หน้าที่มีความเสี่ยงสูงสุด: ตะกร้าสินค้าและหน้าชำระเงิน

หน้าตะกร้าสินค้าต้องเป็น HTTPS ตั้งแต่กดเพิ่มสินค้าชิ้นแรก

ตรวจว่าหน้าตะกร้าสินค้าเป็น HTTPS ตั้งแต่โหลดครั้งแรก ไม่ใช่เปลี่ยนเป็น HTTPS ตอนกดปุ่ม \"ดำเนินการชำระเงิน\" เท่านั้น เพราะข้อมูลสินค้าที่เลือกและราคาที่แสดงในตะกร้าถือเป็นข้อมูลที่ควรเข้ารหัสตลอดเส้นทาง ไม่ใช่แค่ขั้นตอนสุดท้าย

ฟอร์มที่อยู่จัดส่งและข้อมูลติดต่อต้องอยู่บนหน้า HTTPS เสมอ

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

ทดสอบเส้นทางเชื่อมต่อไปยังหน้าชำระเงินของผู้ให้บริการภายนอก

เปิดหน้าชำระเงินจริง แล้วดูแถบที่อยู่ของเบราว์เซอร์ว่ายังคง HTTPS ตลอดเส้นทางหรือไม่ รวมถึงตรวจว่าไม่มีการ Redirect ผ่าน HTTP ก่อนไปถึงหน้าชำระเงินปลายทาง แม้จะเป็นการ Redirect ชั่วขณะก็ถือว่าเสี่ยง

เช็ก Mixed Content จากปลั๊กอินการตลาดและวิดเจ็ตรีวิว

วิดเจ็ตรีวิวสินค้าและป้ายส่วนลดจากบุคคลที่สาม

ร้านค้าที่ใช้วิดเจ็ตรีวิวสินค้า ป้ายนับถอยหลังโปรโมชัน หรือแบนเนอร์จากผู้ให้บริการภายนอก ควรตรวจว่าสคริปต์เหล่านี้อ้างอิง URL แบบ https:// ทั้งหมด เพราะเป็นสคริปต์ที่ทีมการตลาดมักเพิ่มเองโดยไม่ผ่านทีมพัฒนา และไม่ได้ถูกตรวจสอบ Mixed Content ตั้งแต่แรก

รูปภาพสินค้าที่อัปโหลดผ่านระบบเก่าหรือย้ายมาจากแพลตฟอร์มอื่น

ร้านที่เคยย้ายแพลตฟอร์มหรือนำเข้าสินค้าจำนวนมากด้วยไฟล์ CSV มักมี URL รูปภาพสินค้าบางส่วนที่ยังชี้ไปที่ http:// ของระบบเดิม ควรสุ่มตรวจสินค้าที่นำเข้าเป็นชุดใหญ่ ไม่ใช่แค่สินค้าที่เพิ่มเข้าใหม่ล่าสุด

สคริปต์ติดตามยอดขายและโฆษณาที่แอดมินเพิ่มเอง

โค้ดติดตามยอดขายจากแพลตฟอร์มโฆษณา หรือโค้ด Affiliate ที่แอดมินร้านคัดลอกมาวางเอง เป็นอีกจุดที่มักหลุดรอดการตรวจสอบทางเทคนิค เพราะถูกเพิ่มนอกรอบการพัฒนาเว็บไซต์ปกติ ควรมีรอบตรวจสอบ Mixed Content ทุกครั้งที่มีการเพิ่มสคริปต์จากทีมการตลาด

เช็กความสัมพันธ์ระหว่าง HTTPS กับ Payment Gateway และ Trust Badge

Payment Gateway ส่วนใหญ่กำหนดเป็นเงื่อนไขอยู่แล้วว่าเว็บไซต์ที่เชื่อมต่อต้องใช้ HTTPS แต่ร้านค้าควรตรวจซ้ำด้วยตัวเองว่าใบรับรอง TLS ของโดเมนหลักยังไม่หมดอายุและครอบคลุมโดเมนที่ใช้เชื่อมต่อ API จริง เพราะ Payment Gateway มักตรวจตอนเชื่อมต่อครั้งแรกเท่านั้น ไม่ได้เฝ้าระวังการหมดอายุให้ตลอดไป

ป้าย Trust Badge ที่ร้านค้าติดไว้เพื่อสร้างความมั่นใจ เช่นสัญลักษณ์ล็อกหรือชื่อผู้ให้บริการชำระเงิน ไม่มีความหมายหากเว็บไซต์เองไม่ได้เป็น HTTPS ที่ถูกต้อง ลูกค้าที่สังเกตแถบที่อยู่เบราว์เซอร์จะเห็นความไม่สอดคล้องกันทันที ซึ่งบั่นทอนความน่าเชื่อถือมากกว่าการไม่มี Trust Badge เลยเสียอีก

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

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

Mixed Content จากปลั๊กอินการตลาดตรวจได้อย่างไรโดยไม่ต้องเป็นโปรแกรมเมอร์ เปิดหน้าร้านด้วยเบราว์เซอร์ แล้วดูสัญลักษณ์ล็อกหรือคำเตือนที่แถบที่อยู่ หากมี Mixed Content เบราว์เซอร์ส่วนใหญ่จะแสดงคำเตือนหรือไอคอนพิเศษให้เห็นโดยไม่ต้องเปิดเครื่องมือนักพัฒนา แต่การหาว่าสคริปต์ตัวไหนเป็นต้นเหตุยังต้องใช้ทีมเทคนิคช่วยตรวจ

Payment Gateway ตรวจสอบ HTTPS ของร้านค้าให้ตลอดไปหรือไม่ ส่วนใหญ่ Payment Gateway ตรวจเงื่อนไข HTTPS เฉพาะตอนเชื่อมต่อครั้งแรกเท่านั้น ไม่ได้เฝ้าระวังการหมดอายุของใบรับรองให้ตลอดไป ร้านค้าจึงต้องตรวจซ้ำด้วยตัวเองเป็นระยะ

ควรตรวจ Mixed Content บ่อยแค่ไหนสำหรับร้านค้าที่มีทีมการตลาดเพิ่มสคริปต์เองบ่อย ควรตรวจทุกครั้งที่มีการเพิ่มสคริปต์หรือวิดเจ็ตใหม่จากทีมการตลาด ไม่ใช่รอตรวจตามรอบเวลาเท่านั้น เพราะสคริปต์เหล่านี้มักถูกเพิ่มนอกรอบการพัฒนาเว็บไซต์ปกติ และเป็นสาเหตุอันดับต้น ๆ ที่ทำให้ร้านที่เคยผ่านการตรวจแล้วกลับมามี Mixed Content ใหม่โดยไม่มีใครสังเกต

เช็กลิสต์ปฏิบัติ

• ตรวจว่าหน้าตะกร้าสินค้าเป็น HTTPS ตั้งแต่กดเพิ่มสินค้าชิ้นแรก ไม่ใช่แค่ตอนชำระเงิน
• ตรวจฟอร์มที่อยู่จัดส่งและข้อมูลติดต่อว่าอยู่บนหน้า HTTPS เสมอ
• ทดสอบเส้นทางเชื่อมต่อไปยังหน้าชำระเงินของผู้ให้บริการภายนอกว่าไม่มีการ Redirect ผ่าน HTTP ระหว่างทาง
• ตรวจสคริปต์วิดเจ็ตรีวิวและป้ายส่วนลดจากบุคคลที่สามว่าอ้างอิง URL แบบ https:// ทั้งหมด
• สุ่มตรวจรูปภาพสินค้าที่นำเข้าด้วยไฟล์ CSV หรือย้ายมาจากแพลตฟอร์มอื่น
• ตรวจสคริปต์ติดตามยอดขายและโค้ด Affiliate ที่แอดมินร้านเพิ่มเองทุกครั้งที่มีการเพิ่มใหม่
• ตรวจว่าใบรับรอง TLS ของโดเมนหลักครอบคลุมโดเมนที่ใช้เชื่อมต่อ Payment Gateway จริง
• ยืนยันว่า Trust Badge ที่ติดไว้สอดคล้องกับสถานะ HTTPS จริงของร้าน

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

• ปล่อยให้หน้าตะกร้าสินค้าเป็น HTTP จนกว่าจะกดปุ่มดำเนินการชำระเงินจึงเปลี่ยนเป็น HTTPS
• เพิ่มวิดเจ็ตรีวิวหรือสคริปต์การตลาดโดยไม่ตรวจว่าอ้างอิง URL แบบ https:// ก่อนนำขึ้นเว็บจริง
• เข้าใจผิดว่าเมื่อเชื่อมต่อ Payment Gateway สำเร็จครั้งแรกแล้ว ไม่ต้องตรวจใบรับรอง TLS ของโดเมนหลักซ้ำอีก
• ไม่ตรวจรูปภาพสินค้าที่นำเข้าเป็นชุดใหญ่จากระบบเก่า ปล่อยให้มี URL แบบ http:// หลงเหลืออยู่
• ติด Trust Badge บนหน้าที่ยังมี Mixed Content ทำให้ลูกค้าสับสนระหว่างสิ่งที่เห็นกับสิ่งที่ป้ายบอก

สรุป

สำหรับร้านค้าออนไลน์ ความเสี่ยงของ HTTPS และ TLS ไม่ได้อยู่ที่การเปิดใช้งานทั้งเว็บ แต่อยู่ที่จุดต่อระหว่างระบบ เช่นวิดเจ็ตการตลาดที่เพิ่มทีหลัง รูปภาพที่นำเข้าจากระบบเก่า และเส้นทางเชื่อมต่อไปยังผู้ให้บริการชำระเงิน การตรวจหน้าตะกร้าและหน้าชำระเงินเป็นประจำ พร้อมสุ่มตรวจสคริปต์ที่ทีมการตลาดเพิ่มเอง ช่วยลดโอกาสที่ลูกค้าจะเห็นคำเตือนความปลอดภัยตอนใกล้ปิดการขาย

แหล่งข้อมูลอ้างอิง

• OWASP HTTP Security Response Headers Cheat Sheet
• ศูนย์ความรู้ด้านความปลอดภัยเว็บไซต์ของ trusty
• วิธีวางระบบ HTTPS และ TLS สำหรับร้านค้าออนไลน์แบบเป็นขั้นตอน
• วิธี Audit HTTPS และ TLS ของร้านค้าออนไลน์พร้อม Evidence ที่ควรเก็บ