วิธี Audit HTTP Security Headers ขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง พร้อม Evidence ที่ควรเก็บ

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

บทความนี้อธิบายขั้นตอน Audit HTTP Security Headers สำหรับทีมกฎหมาย Privacy Security และ Compliance ที่ต้องการคำตอบที่ตรวจสอบย้อนกลับได้ ไม่ใช่แค่ความรู้สึกว่าน่าจะตั้งค่าไว้แล้ว

วิธีตรวจว่าโดเมนมี Header เหล่านี้อยู่แล้วหรือยัง

วิธีที่ตรงที่สุดคือดู Response Header จริงที่เซิร์ฟเวอร์ส่งกลับมา ไม่ใช่ดูจากเอกสารการตั้งค่าที่อาจไม่ตรงกับสิ่งที่ใช้งานจริงบน Production

เครื่องมือพัฒนาเว็บที่มากับเบราว์เซอร์ทุกตัว (แท็บ Network) แสดง Response Header ของทุกคำขอได้โดยไม่ต้องติดตั้งเพิ่ม เปิดหน้าเว็บที่ต้องการตรวจ กดปุ่มโหลดหน้าใหม่ แล้วเลือกคำขอเอกสาร HTML หลักเพื่อดู Header ที่แนบมา

อีกวิธีหนึ่งที่เหมาะกับการตรวจหลายโดเมนพร้อมกันคือใช้คำสั่งบรรทัดคำสั่งอย่าง curl พร้อมออปชันที่ดึงเฉพาะ Header โดยไม่ต้องโหลดเนื้อหาทั้งหน้า วิธีนี้เหมาะกับทีมเทคนิคที่ต้องการทำสคริปต์ตรวจซ้ำเป็นประจำ

ไม่ว่าจะใช้เครื่องมือใด หลักการเดียวกันคือต้องตรวจจากคำขอจริงที่ไปถึงเซิร์ฟเวอร์ Production ไม่ใช่ Staging หรือเครื่องพัฒนาส่วนตัว เพราะค่า Header อาจถูกเพิ่มหรือถูกเอาออกโดย Reverse Proxy, CDN หรือ Web Application Firewall ระหว่างทาง ซึ่งอาจต่างจากค่าที่ตั้งไว้ในโค้ดต้นทาง

อ่านผลตรวจแต่ละ Header อย่างไร

เมื่อได้รายการ Header ที่เซิร์ฟเวอร์ส่งกลับมาแล้ว ขั้นต่อไปคืออ่านความหมายของแต่ละค่า ไม่ใช่แค่เช็กว่ามีชื่อ Header นั้นปรากฏหรือไม่

Strict-Transport-Security ต้องดูค่า max-age ว่านานพอหรือไม่ และมี includeSubDomains หรือไม่หากองค์กรต้องการบังคับ HTTPS ทั้ง Subdomain ค่า max-age ที่สั้นเกินไปแทบไม่มีผลป้องกันในทางปฏิบัติ

X-Content-Type-Options ควรมีค่าเป็น nosniff เท่านั้น ค่าอื่นถือว่าไม่ได้ผลตามวัตถุประสงค์ของ Header นี้

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

Referrer-Policy ต้องอ่านควบคู่กับโครงสร้าง URL ของเว็บไซต์ หากมี Path หรือ Query String ที่มีข้อมูลลูกค้าอยู่ ค่าที่ตั้งไว้ต้องไม่ส่งข้อมูลนั้นออกไปยังปลายทางภายนอกแบบเต็มรูปแบบ

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

Evidence ที่ควรเก็บสำหรับรอบ Audit ภายในและภายนอก

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

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

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

การ Audit ข้ามโดเมนและ Subdomain ในองค์กรที่มีหลายระบบ

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

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

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

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

เครื่องมือตรวจอัตโนมัติช่วยได้แค่ไหน

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

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

อีกข้อจำกัดคือเครื่องมือสแกนมักตรวจแค่หน้าแรกหรือหน้าที่ระบุไว้ ไม่ได้ไล่ตรวจทุกหน้าในเว็บไซต์ หน้า Login หรือหน้าทำธุรกรรมที่อยู่ลึกในระบบอาจไม่ถูกสแกนเลยหากไม่ระบุ URL ไว้ตรง ๆ ทีมที่รับผิดชอบ Audit จึงควรเลือกหน้าสำคัญด้วยตัวเองแทนที่จะพึ่งพาการสแกนอัตโนมัติเพียงอย่างเดียว

การรายงานผล Audit ต่อฝ่ายกฎหมายและผู้บริหาร

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

ตัวอย่างเช่น หากพบว่าหน้า Login ของ Portal ลูกค้าไม่มีการควบคุมการฝัง iframe รายงานควรอธิบายว่าช่องว่างนี้เปิดโอกาสให้หน้า Login ถูกฝังในเว็บไซต์อื่นเพื่อหลอกผู้ใช้ ไม่ใช่แค่บอกว่า Header ที่ชื่อ X-Frame-Options หายไป

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

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

เมื่อองค์กรมีรอบทบทวนความปลอดภัยเว็บไซต์เป็นระยะอยู่แล้ว ผลตรวจ Header ควรผนวกเข้าไปเป็นส่วนหนึ่งของรอบนั้น แนวทางการวางรอบทบทวนอธิบายเพิ่มเติมไว้ใน อัปเดต HTTP Security Headers ปี 2026 สำหรับ Enterprise

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

ต้องตรวจ Header ด้วยเครื่องมือเฉพาะทางหรือไม่ ไม่จำเป็นสำหรับการตรวจเบื้องต้น เครื่องมือพัฒนาเว็บในเบราว์เซอร์หรือคำสั่งบรรทัดคำสั่งพื้นฐานก็เพียงพอสำหรับดู Response Header จริง

ควร Audit บ่อยแค่ไหน ควรทำอย่างน้อยทุกครั้งที่มีการเปลี่ยนแปลงโครงสร้างพื้นฐาน เช่น เปลี่ยน CDN เปลี่ยนโฮสติ้ง หรือเพิ่มโดเมนใหม่ และควรมีรอบทบทวนตามระยะเวลาที่องค์กรกำหนดเพิ่มเติม

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

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

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

• ทำทะเบียนโดเมนและ Subdomain ทั้งหมดที่องค์กรเป็นเจ้าของหรือดูแลอยู่ก่อนเริ่ม Audit
• ตรวจ Response Header จริงจาก Production ของแต่ละโดเมนในทะเบียน ไม่ใช่จาก Staging หรือเอกสารเก่า
• อ่านค่าของแต่ละ Header ไม่ใช่แค่เช็กว่ามีชื่อ Header ปรากฏ
• เก็บผลตรวจแบบดิบพร้อมวันที่ ชื่อโดเมน และผู้ตรวจไว้เป็นหลักฐาน
• ระบุผู้รับผิดชอบแก้ไขของแต่ละโดเมนที่พบช่องว่าง โดยเฉพาะโดเมนที่ทีมภายนอกดูแล
• เขียนรายงานผลที่แยกระหว่างสิ่งที่ตรวจพบจริงกับข้อสรุปเชิงความเสี่ยงให้ชัดเจน
• นัดรอบตรวจซ้ำหลังการเปลี่ยนแปลงโครงสร้างพื้นฐานทุกครั้ง
• ผนวกผลตรวจ Header เข้ากับรอบทบทวนความปลอดภัยเว็บไซต์ที่องค์กรมีอยู่แล้ว

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

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

สรุป

การ Audit HTTP Security Headers ที่น่าเชื่อถือต้องอิงจาก Response Header จริงของ Production ไม่ใช่เอกสารหรือความทรงจำ พร้อมเก็บหลักฐานที่ตรวจสอบย้อนกลับได้และรายงานผลในภาษาที่ผู้บริหารและฝ่ายกฎหมายเข้าใจผลกระทบจริง โดยไม่สรุปเกินกว่าสิ่งที่ผลตรวจ Header แสดงให้เห็นจริง

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project