เช็กลิสต์ HTTP Security Headers สำหรับคลินิก โรงพยาบาล และธุรกิจสุขภาพ

ฟอร์มนัดหมายออนไลน์ของคลินิกมักฝังมาจากระบบ Third-party อย่างระบบคิว ระบบ Telemed หรือปลั๊กอินจองคิวที่ทีมการตลาดติดตั้งเอง โดยที่ทีมพัฒนาเว็บไม่ได้ตรวจ Header ของหน้านั้นซ้ำอีกครั้ง ข้อมูลที่กรอกในฟอร์มเหล่านี้มักเป็นชื่อ เบอร์โทร อาการเบื้องต้น หรือแม้แต่ประวัติการรักษา ซึ่งเข้าข่ายข้อมูลสุขภาพที่ PDPA จัดเป็นข้อมูลอ่อนไหว การไม่มี HTTP Security Headers ที่เหมาะสมบนหน้าประเภทนี้จึงเป็นความเสี่ยงที่ต่างจากเว็บขายของทั่วไปตรงที่ผลกระทบเมื่อเกิดปัญหาจะกระทบข้อมูลอ่อนไหวโดยตรง

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

ทำไม Header สำหรับหน้าสุขภาพต้องเข้มกว่าหน้าเว็บทั่วไป

หน้าแรกของเว็บคลินิกมักเป็นเนื้อหาสาธารณะที่ความเสี่ยงต่ำ แต่หน้าฟอร์มนัดหมาย หน้าอัปโหลดผลตรวจ หรือหน้าที่เชื่อมกับระบบ Telemed คือจุดที่ข้อมูลอ่อนไหวไหลเข้าออก หากหน้าพวกนี้ถูกฝังในหน้าอื่นผ่าน iframe โดยไม่ได้รับอนุญาต (Clickjacking) หรือถูกดักอ่าน Referrer ที่มี Token ของผู้ป่วยติดไปกับ URL ผลกระทบจะเป็นข้อมูลสุขภาพหลุด ไม่ใช่แค่หน้าเว็บล่ม

จุดที่มักถูกมองข้าม

วิดเจ็ตจองคิวจากผู้ให้บริการภายนอกมักมาพร้อม Script และ iframe ของตัวเอง ทีมการตลาดที่ติดตั้งโค้ดตามคู่มือผู้ให้บริการมักไม่รู้ว่าการเพิ่ม Script นั้นอาจทำให้ Content-Security-Policy เดิมของเว็บใช้งานไม่ได้ หรือทำให้ทีมพัฒนาต้องเปิดโดเมนใหม่ให้ Script รันได้ ซึ่งถ้าเปิดกว้างเกินไปก็จะลดประโยชน์ของ CSP ลง

เช็กลิสต์ Header ที่ต้องตรวจก่อนเปิดใช้งาน

ต่อไปนี้คือ Header หลักที่ OWASP แนะนำให้ตรวจ พร้อมมุมมองเฉพาะสำหรับหน้าที่มีข้อมูลสุขภาพ

Strict-Transport-Security (HSTS)

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

X-Content-Type-Options: nosniff

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

X-Frame-Options หรือ frame-ancestors ใน CSP

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

Referrer-Policy

ควบคุมว่าจะส่งข้อมูล URL ต้นทางไปให้เว็บปลายทางมากแค่ไหน หากหน้านัดหมายมี Token หรือรหัสอ้างอิงคนไข้ติดอยู่ใน URL การตั้งค่าเป็น strict-origin-when-cross-origin หรือเข้มกว่านั้นจะช่วยลดโอกาสที่ข้อมูลอ้างอิงคนไข้รั่วไปกับ Referrer เมื่อมีการคลิกลิงก์ออกจากหน้านั้น

Content-Security-Policy (CSP)

เป็น Header ที่ตั้งค่ายากที่สุดในกลุ่มนี้ เพราะต้องระบุโดเมนที่อนุญาตให้โหลด Script, Style และ Frame ได้ สำหรับเว็บคลินิกที่มีวิดเจ็ตนัดหมาย ระบบแชท และพิกเซลการตลาดพร้อมกัน แนะนำให้เริ่มจากโหมด Content-Security-Policy-Report-Only เพื่อดูว่ามีอะไรถูกบล็อกก่อนบังคับใช้จริง แล้วค่อยไล่เพิ่มโดเมนที่จำเป็นทีละรายการ ไม่ใช่เปิดกว้างด้วย wildcard เพื่อความสะดวก

Permissions-Policy

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

ประสานงานระหว่างทีมการตลาดกับทีมพัฒนา

ทีมการตลาดของธุรกิจสุขภาพมักเป็นคนเลือกและติดตั้งวิดเจ็ตนัดหมายหรือฟอร์มจากผู้ให้บริการภายนอกเอง แต่การตั้งค่า Header เป็นงานของทีมพัฒนาเว็บหรือ Hosting ขั้นตอนที่ควรทำทุกครั้งที่มีการเพิ่มวิดเจ็ตใหม่คือแจ้งโดเมนของวิดเจ็ตนั้นให้ทีมพัฒนาทราบล่วงหน้า เพื่อให้ปรับ CSP และ Permissions-Policy ให้รองรับได้ถูกต้อง แทนที่จะปล่อยให้วิดเจ็ตใช้งานไม่ได้แล้วค่อยแก้ไขแบบเร่งด่วนหลังคนไข้ร้องเรียน

วิธีตรวจว่ามี Header ครบก่อนเปิดใช้งานจริง

ก่อนเปิดหน้าฟอร์มใหม่ให้คนไข้ใช้งาน ให้ตรวจ Response Header ของหน้านั้นผ่าน Developer Tools ในเบราว์เซอร์ หรือเครื่องมือตรวจสอบ Header ออนไลน์ โดยดูที่แท็บ Network แล้วเลือก Request หลักของหน้า จากนั้นดูใน Response Headers ว่ามีรายการที่กล่าวถึงข้างต้นครบหรือไม่ หากใช้ trusty การสแกน Header ภายนอกช่วยดูภาพรวมได้ในระดับหนึ่ง แต่ควรตรวจซ้ำด้วยตาบนหน้าที่มีฟอร์มจริงเสมอ เพราะบางระบบตั้งค่า Header แยกกันตามเส้นทาง URL

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

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

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

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

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

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

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

• ตรวจ Strict-Transport-Security บนทุกโดเมนย่อยที่คนไข้เข้าถึง ไม่ใช่แค่โดเมนหลัก
• เปิด X-Content-Type-Options: nosniff บนทุกหน้ารวมถึงหน้าดาวน์โหลดผลตรวจ
• ตั้งค่า frame-ancestors หรือ X-Frame-Options บนหน้าฟอร์มนัดหมายและหน้าชำระเงิน
• ตรวจ Referrer-Policy บนหน้าที่มี Token หรือรหัสอ้างอิงคนไข้ใน URL
• ทดสอบ CSP ในโหมด Report-Only ก่อนบังคับใช้จริงทุกครั้งที่เพิ่มวิดเจ็ตใหม่
• จำกัด Permissions-Policy ให้เฉพาะโดเมน Telemed จริงที่ต้องใช้กล้องและไมค์
• แจ้งทีมพัฒนาเว็บทุกครั้งที่ทีมการตลาดติดตั้งวิดเจ็ตหรือฟอร์มใหม่จากภายนอก
• ตรวจ Response Header ซ้ำผ่าน Developer Tools หลังทุกการอัปเดตหน้าเว็บ

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

• ติดตั้งวิดเจ็ตนัดหมายใหม่โดยไม่แจ้งทีมพัฒนา ทำให้ CSP บล็อกวิดเจ็ตแบบเงียบและกดจองไม่ได้
• ตั้งค่า CSP กว้างเกินไปด้วย wildcard เพื่อให้ใช้งานได้เร็ว จนไม่มีประโยชน์ในการป้องกัน
• ตรวจ Header เฉพาะหน้าแรกของเว็บ แต่ไม่ตรวจหน้าฟอร์มนัดหมายหรือหน้า Telemed ที่มีข้อมูลอ่อนไหวจริง
• ลืมตั้ง Permissions-Policy จำกัดสิทธิ์กล้องและไมค์ ทำให้ทุกโดเมนขอสิทธิ์ได้โดยไม่จำเป็น
• ไม่ตรวจซ้ำหลังผู้ให้บริการวิดเจ็ตอัปเดตระบบของเขาเอง ซึ่งอาจเปลี่ยนโดเมนที่เรียกใช้

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project
• คู่มือ HTTP Security Headers ฉบับพื้นฐาน
• ศูนย์ความรู้ Website Security ของ trusty