HTTP Security Headers คืออะไร? คู่มือสำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง

เว็บไซต์ขององค์กรการเงิน ประกันภัย และธุรกิจที่มีความเสี่ยงสูง มักมีหน้า Login เข้าระบบสมาชิก หน้าชำระเงิน หรือฟอร์มขอใบเสนอราคาที่เชื่อมกับข้อมูลบัญชีจริง HTTP Security Headers จึงไม่ใช่แค่รายการที่ผ่านเกณฑ์ในเครื่องมือสแกนความปลอดภัยทั่วไป แต่เป็นสิ่งที่คู่ค้าธนาคาร ผู้ให้บริการ Payment Gateway และผู้ตรวจสอบภายนอกมักขอดูเป็นหลักฐานประกอบก่อนอนุมัติการเชื่อมต่อระบบ หรือก่อนต่อสัญญาประจำปี

คู่มือนี้เขียนขึ้นสำหรับทีมองค์กร ฝ่ายกฎหมาย Privacy Security และ Compliance โดยเน้นมุมที่ธุรกิจทั่วไปไม่ค่อยต้องเจอ ได้แก่ เหตุผลที่คู่ค้าธนาคารขอดู Security Headers ก่อนเซ็นสัญญา ผลกระทบของ Header ต่อหน้า Login และฟอร์มชำระเงินโดยตรง การตั้งค่า CSP ให้ทำงานร่วมกับ Widget ชำระเงินจากผู้ให้บริการภายนอก ความสอดคล้องของ Header ระหว่างสภาพแวดล้อมทดสอบกับ Production และการเตรียมเอกสารให้พร้อมสำหรับผู้ตรวจสอบ

เหตุใดคู่ค้าธนาคารและผู้ตรวจสอบภายนอกถึงขอดู Security Headers ก่อนเซ็นสัญญา

เมื่อองค์กรการเงินต้องเชื่อมต่อระบบกับธนาคารหรือผู้ให้บริการ Payment Gateway ฝ่าย Security ของคู่ค้ามักส่งแบบสอบถามหรือใช้เครื่องมือสแกน Header จากภายนอกเพื่อประเมินความเสี่ยงเบื้องต้นก่อนอนุมัติการเชื่อมต่อ เพราะ Header อย่าง Strict-Transport-Security หรือ X-Frame-Options เป็นสัญญาณที่บอกได้เร็วว่าทีมพัฒนาเว็บไซต์มีมาตรฐานความปลอดภัยพื้นฐานหรือไม่ โดยไม่ต้องรอผลการทำ Penetration Test แบบเต็มรูปแบบ องค์กรที่ Header ไม่ครบมักถูกขอให้แก้ไขก่อนจึงจะได้รับอนุมัติให้เชื่อมต่อระบบจริง ซึ่งอาจทำให้โครงการล่าช้าหากไม่ได้เตรียมพร้อมไว้ล่วงหน้า

หน้า Login และฟอร์มชำระเงิน กับ Header ที่มีผลโดยตรงต่อความปลอดภัยของ Session

หน้า Login เข้าระบบสมาชิกและหน้ากรอกข้อมูลชำระเงินเป็นจุดที่มีความเสี่ยงสูงสุดหากถูกฝังในหน้าอื่นผ่าน iframe โดยผู้ไม่หวังดี ซึ่งเป็นเทคนิคที่เรียกว่า Clickjacking Header X-Frame-Options หรือ Content-Security-Policy ที่มีคำสั่ง frame-ancestors จึงต้องถูกตั้งค่าให้ปฏิเสธการฝังหน้าเหล่านี้ในโดเมนอื่นโดยเด็ดขาด ยกเว้นกรณีที่มีเหตุผลทางธุรกิจชัดเจน เช่น Widget ที่ฝังในเว็บพันธมิตรที่ผ่านการตรวจสอบแล้วเท่านั้น

อีก Header ที่สำคัญคือ Strict-Transport-Security ซึ่งบังคับให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS เท่านั้นในทุกครั้งถัดไป สำหรับเว็บไซต์การเงินที่ Session Cookie มีอายุการใช้งานค่อนข้างสั้นแต่มีสิทธิ์เข้าถึงข้อมูลบัญชีจริง การไม่มี HSTS หรือค่า max-age สั้นเกินไป เปิดช่องให้เกิดการโจมตีแบบ SSL Stripping ที่ดักจับ Session ระหว่างทางได้ง่ายกว่าที่ควรจะเป็น

CSP กับ Widget ชำระเงินหรือ iframe จากผู้ให้บริการภายนอก

หน้าชำระเงินขององค์กรการเงินมักฝัง Widget จาก Payment Gateway หรือระบบยืนยันตัวตนจากผู้ให้บริการภายนอก การตั้งค่า Content-Security-Policy จึงต้องระบุโดเมนของผู้ให้บริการเหล่านี้ไว้ใน Directive อย่าง script-src และ frame-src อย่างชัดเจน แทนที่จะเปิดกว้างแบบ wildcard ซึ่งลดประสิทธิภาพของ CSP ลงจนแทบไม่มีความหมาย ทีม Security ควรมีรายการโดเมนของผู้ให้บริการภายนอกที่ได้รับอนุมัติแล้วเก็บไว้เป็นเอกสารกลาง และทบทวนทุกครั้งที่มีการเปลี่ยนผู้ให้บริการหรือเพิ่มบริการใหม่เข้ามาในหน้าชำระเงิน

ความสอดคล้องของ Header ระหว่างสภาพแวดล้อมทดสอบกับ Production

สภาพแวดล้อม	ความเสี่ยงหากตั้งค่าไม่ตรงกับ Production	ผู้รับผิดชอบตรวจสอบ
UAT / Pre-Production	ผู้ตรวจสอบเห็นผลสแกนที่ดีกว่าความเป็นจริงของระบบที่ใช้งานจริง	ทีม QA ร่วมกับ Security
Staging ที่เปิดให้เข้าถึงจากภายนอก	อาจกลายเป็นช่องโหว่ที่ไม่มีใครตรวจสอบเพราะคิดว่าเป็นแค่ระบบทดสอบ	ทีม Infra
Production	Header ที่ตกหล่นในจุดนี้กระทบผู้ใช้งานจริงและข้อมูลบัญชีจริง	ทีม Security เป็นผู้ตรวจสอบรอบสุดท้าย

องค์กรจำนวนมากตั้งค่า Header ไว้อย่างเข้มงวดใน Production แต่ลืมตั้งค่าเดียวกันใน UAT หรือ Staging ทำให้เมื่อผู้ตรวจสอบหรือคู่ค้าธนาคารสแกนระบบทดสอบก่อนอนุมัติ กลับเห็นผลลัพธ์ที่ไม่ตรงกับสภาพแวดล้อมจริงที่จะเปิดใช้งาน แนวทางที่ถูกต้องคือใช้ Configuration File ชุดเดียวกันหรือ Template เดียวกันในทุกสภาพแวดล้อม แล้วปรับเฉพาะค่าที่จำเป็นต้องต่างกันจริง เช่น โดเมนที่อนุญาตใน CSP เท่านั้น

ใครเป็นเจ้าของ Header จริง ทีม Infra WAF CDN หรือทีม Application

ในองค์กรขนาดใหญ่ Header บางตัวถูกตั้งค่าโดย WAF หรือ CDN ที่ทีม Infrastructure ดูแล ในขณะที่ Header บางตัวถูกตั้งค่าในโค้ดของแอปพลิเคชันโดยทีม Development เมื่อทั้งสองฝ่ายไม่ได้สื่อสารกันชัดเจน อาจเกิดกรณีที่ Header ถูกตั้งค่าซ้ำซ้อนจนขัดแย้งกันเอง หรือฝ่ายหนึ่งเข้าใจผิดว่าอีกฝ่ายดูแลอยู่แล้วจนไม่มีใครตั้งค่าจริง แนวทางแก้ไขคือทำเอกสาร Ownership Matrix ที่ระบุชัดว่า Header แต่ละตัวถูกควบคุมที่ชั้นไหน ใครเป็นผู้แก้ไขได้ และต้องแจ้งใครเมื่อมีการเปลี่ยนแปลง เพื่อไม่ให้เกิดช่องว่างระหว่างทีมที่ไม่มีใครรับผิดชอบจริง

Referrer-Policy กับความเสี่ยงที่หมายเลขบัญชีหรือ Token รั่วผ่าน URL

ระบบธนาคารและประกันภัยหลายแห่งยังคงส่งพารามิเตอร์ที่ระบุตัวตนหรือหมายเลขอ้างอิงธุรกรรมผ่าน Query String ในบาง Flow เช่น หน้ายืนยันผลอนุมัติหรือหน้าติดตามสถานะกรมธรรม์ หากหน้าดังกล่าวมีการโหลด Script วิเคราะห์ผลหรือ Font จากผู้ให้บริการภายนอก และไม่ได้ตั้งค่า Referrer-Policy ให้รัดกุม เบราว์เซอร์อาจส่ง URL เต็มรวมถึงพารามิเตอร์เหล่านั้นไปยังปลายทางภายนอกโดยไม่ตั้งใจผ่าน Header Referer ที่แนบไปกับทุกคำขอถัดไป

ค่าที่แนะนำสำหรับหน้าที่มีความละเอียดอ่อนสูงคือ strict-origin-when-cross-origin หรือเข้มงวดกว่านั้นคือ no-referrer สำหรับหน้าที่ไม่จำเป็นต้องส่ง Referrer ออกไปเลย ทีม Security ควรตรวจสอบเฉพาะหน้าที่มีพารามิเตอร์อ้างอิงธุรกรรมในทุกโดเมนย่อยขององค์กร เพราะบางระบบเก่าที่พัฒนาแยกทีมกันอาจยังไม่ได้ตั้งค่านี้ไว้ตั้งแต่ต้น แม้หน้าหลักขององค์กรจะตั้งค่าไว้ถูกต้องแล้วก็ตาม

X-Content-Type-Options กับไฟล์ที่ผู้ใช้งานอัปโหลดเข้าระบบ

ระบบประกันภัยและธนาคารมักเปิดให้ลูกค้าอัปโหลดเอกสารประกอบ เช่น สำเนาบัตรประชาชนหรือหลักฐานอุบัติเหตุ หากเซิร์ฟเวอร์ไม่ได้ตั้งค่า X-Content-Type-Options เป็น nosniff เบราว์เซอร์บางตัวอาจพยายามเดาประเภทไฟล์เองจากเนื้อหาแทนที่จะเชื่อ Content-Type ที่เซิร์ฟเวอร์ระบุไว้ ซึ่งเปิดช่องให้ไฟล์ที่ถูกดัดแปลงให้ดูเหมือนรูปภาพแต่แฝง Script ไว้ข้างในถูกเบราว์เซอร์ตีความและรันขึ้นมาได้ในบางสถานการณ์ การตั้งค่า Header นี้เป็นมาตรการพื้นฐานที่ควรมีคู่กับการตรวจสอบชนิดไฟล์ฝั่งเซิร์ฟเวอร์อีกชั้นหนึ่งเสมอ ไม่ใช่พึ่งพา Header เพียงอย่างเดียว

การเตรียมเอกสารให้พร้อมสำหรับผู้ตรวจสอบ

เมื่อถึงรอบตรวจสอบประจำปีหรือมีการขอ Vendor Security Questionnaire จากคู่ค้า ทีม Security ควรมีผลสแกน Header ล่าสุดพร้อมวันที่ตรวจสอบ รายการ Header ที่ตั้งค่าไว้พร้อมเหตุผลของแต่ละค่า และบันทึกการเปลี่ยนแปลง Header ย้อนหลังที่เชื่อมกับ Ownership Matrix ข้างต้น เอกสารชุดนี้ควรถูกอัปเดตเป็นประจำ ไม่ใช่รวบรวมเร่งด่วนเฉพาะตอนถูกขอเท่านั้น เพราะจะทำให้ผู้ตรวจสอบเห็นว่าองค์กรมีกระบวนการติดตามอย่างต่อเนื่องจริง ไม่ใช่แค่แก้ปัญหาเฉพาะหน้าก่อนตรวจ

การนำไปใช้จริงร่วมกับระบบอื่น

Security Headers เป็นเพียงส่วนหนึ่งของการป้องกันเว็บไซต์องค์กรการเงิน ควรทำงานร่วมกับการตั้งค่า Consent Mode ที่ควบคุมข้อมูลผู้ใช้งานอีกชั้นหนึ่ง ดูวิธีตั้งค่าได้ที่ คู่มือ Google Consent Mode สำหรับองค์กรการเงินและธุรกิจความเสี่ยงสูง และภาพรวมการตั้งค่า Cookie Consent Banner ได้ที่ คู่มือ Cookie Consent Banner สำหรับองค์กรความเสี่ยงสูง

หากต้องการตรวจสอบว่าเว็บไซต์ขององค์กรตั้งค่า Security Headers ครบถ้วนหรือยัง ลองใช้ เครื่องมือตรวจสอบเว็บไซต์ฟรีของ trusty

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

ทำไมคู่ค้าธนาคารถึงขอดู Security Headers ก่อนอนุมัติการเชื่อมต่อระบบ

เพราะ Header อย่าง HSTS หรือ X-Frame-Options เป็นสัญญาณที่บอกได้เร็วว่าทีมพัฒนามีมาตรฐานความปลอดภัยพื้นฐานหรือไม่ โดยไม่ต้องรอผลการทำ Penetration Test แบบเต็มรูปแบบ

หน้าชำระเงินควรตั้งค่า X-Frame-Options หรือ frame-ancestors อย่างไร

ควรปฏิเสธการฝังหน้าชำระเงินในโดเมนอื่นโดยเด็ดขาด ยกเว้นกรณีมี Widget ที่ฝังในเว็บพันธมิตรที่ผ่านการตรวจสอบแล้วเท่านั้น เพื่อป้องกัน Clickjacking

CSP ควรอนุญาตโดเมนของ Payment Gateway อย่างไรให้ปลอดภัย

ควรระบุโดเมนของผู้ให้บริการที่ได้รับอนุมัติแล้วไว้ใน Directive อย่าง script-src และ frame-src อย่างชัดเจน แทนที่จะเปิดกว้างแบบ wildcard ซึ่งลดประสิทธิภาพของ CSP ลงจนแทบไม่มีความหมาย

ทำไม Header ใน UAT กับ Production ต้องตั้งค่าให้ตรงกัน

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

ใครควรเป็นเจ้าของ Header ระหว่างทีม Infra กับทีม Application

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

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

• ตั้งค่า X-Frame-Options หรือ frame-ancestors ให้ปฏิเสธการฝังหน้า Login และหน้าชำระเงินในโดเมนอื่น
• ตั้งค่า Strict-Transport-Security ด้วย max-age ที่ยาวเพียงพอสำหรับหน้าที่มีข้อมูลบัญชี
• ระบุโดเมนของ Payment Gateway และผู้ให้บริการภายนอกใน CSP อย่างชัดเจน ไม่ใช้ wildcard
• ใช้ Configuration Template เดียวกันระหว่าง UAT Staging และ Production
• ทำเอกสาร Ownership Matrix ระบุผู้รับผิดชอบ Header แต่ละตัวระหว่างทีม Infra และ Application
• เก็บผลสแกน Header ล่าสุดพร้อมบันทึกการเปลี่ยนแปลงไว้สำหรับผู้ตรวจสอบ

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

• ปล่อยให้หน้าชำระเงินถูกฝังในโดเมนอื่นได้เพราะไม่ได้ตั้งค่า X-Frame-Options หรือ frame-ancestors
• เปิด CSP แบบ wildcard เพื่อความสะดวกจนแทบไม่มีการป้องกันจริง
• ตั้งค่า Header เข้มงวดใน Production แต่ลืมตั้งค่าเดียวกันใน UAT หรือ Staging
• ไม่มีเอกสารระบุว่าทีมใดเป็นเจ้าของ Header แต่ละตัว ทำให้เกิดช่องว่างที่ไม่มีใครดูแล
• รวบรวมเอกสารหลักฐาน Header เฉพาะตอนถูกผู้ตรวจสอบขอเท่านั้น ไม่มีการติดตามต่อเนื่อง

สรุป

สำหรับองค์กรการเงิน ประกันภัย และธุรกิจที่มีความเสี่ยงสูง HTTP Security Headers เป็นมากกว่ารายการที่ต้องผ่านเกณฑ์เครื่องมือสแกน แต่เป็นหลักฐานที่คู่ค้าธนาคารและผู้ตรวจสอบภายนอกใช้ประเมินความพร้อมด้านความปลอดภัยก่อนอนุมัติการเชื่อมต่อระบบ การตั้งค่าที่ปกป้องหน้า Login และหน้าชำระเงินโดยตรง การจัดการ CSP ให้ทำงานร่วมกับผู้ให้บริการภายนอกอย่างรัดกุม ความสอดคล้องระหว่างสภาพแวดล้อม และการกำหนด Ownership ที่ชัดเจน ล้วนเป็นองค์ประกอบที่ทำให้องค์กรพร้อมรับการตรวจสอบได้ทุกเมื่อ ไม่ใช่แค่ตอนใกล้ถึงรอบตรวจ

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

• MDN — Strict-Transport-Security
• MDN — Content-Security-Policy
• OWASP — Secure Headers Project