เช็กลิสต์ HTTP Security Headers สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

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

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

เช็กสิทธิ์เข้าถึงและเจ้าของระบบก่อนเริ่มแตะ Header

• ยืนยันแล้วว่าใครเป็นเจ้าของการตัดสินใจเรื่อง Header ฝั่งลูกค้า และเอเจนซีมีสิทธิ์แก้ไขระดับใดบ้าง
• ตรวจแล้วว่าเว็บอยู่หลัง CDN หรือ Load Balancer ที่เอเจนซีเข้าไม่ถึงหรือไม่
• รู้แล้วว่าเว็บใช้ CMS หรือแพลตฟอร์มอะไร เพราะแต่ละแบบตั้งค่า Header ได้ต่างกัน
• สำรวจ Header เดิมที่มีอยู่แล้วก่อนแก้ไข โดยเฉพาะเว็บที่รับงานต่อจากทีมอื่น

เช็ก Header หลักทีละตัว

เช็กจุดที่มักพังหลัง Header เปลี่ยน

• ทดสอบเส้นทางฟอร์มติดต่อและระบบล็อกอินหลังเปลี่ยน Header ทุกครั้ง
• ทดสอบปลั๊กอินหรือแอปเสริมที่ลูกค้าใช้งานอยู่ว่ายังทำงานได้ปกติ
• ทดสอบ Widget หรือ iframe จากบุคคลที่สามที่ฝังอยู่ในหน้าเว็บ
• ตรวจ Console Error บนเบราว์เซอร์หลังเปลี่ยน Header ไม่ใช่แค่ดูว่าหน้าเว็บโหลดขึ้นเฉย ๆ

เช็กก่อนส่งมอบและปิดงาน

• เขียนรายการ Header ที่ตั้งไว้พร้อมค่าที่ใช้จริง ไม่ใช่แค่บอกว่าตั้งครบแล้ว
• ระบุแยกให้ชัดว่า Header ตัวไหนต้องให้ Hosting หรือทีมไอทีของลูกค้าดำเนินการต่อ
• ตกลงรอบ Re-test กับลูกค้าล่วงหน้า โดยเฉพาะหลัง Major Update ของ CMS
• ยืนยันกับลูกค้าว่ารายงานนี้ไม่ใช่การตรวจสอบความปลอดภัยครบทุกด้าน แต่เป็นการตั้งค่า Header พื้นฐานเท่านั้น

ทำไมเช็กลิสต์แบบนี้ถึงต่างจากการทำเว็บของตัวเอง

เว็บของเอเจนซีเองมีแค่หนึ่งสแตกให้ดูแล แต่เว็บลูกค้าแต่ละรายมีสแตก ปลั๊กอิน และ Hosting ต่างกันหมด เช็กลิสต์ที่ใช้ได้กับเว็บของตัวเองจึงมักไม่ครอบคลุมพอสำหรับงานลูกค้า เพราะไม่มีข้อสิทธิ์เข้าถึงและข้อจำกัดของ CDN/Load Balancer ที่อยู่นอกเหนือการควบคุมของทีม การไล่เช็กลิสต์ตามหมวดสิทธิ์เข้าถึงก่อนเสมอช่วยให้ไม่พลาดจุดที่ควบคุมไม่ได้ตั้งแต่ต้น แทนที่จะไปเจอปัญหาตอนใกล้ปิดงานแล้ว

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

เช็กเมื่อรับงานต่อจากทีมเดิมหรือ Hosting เปลี่ยนมือ

• สำรวจ Header เดิมทั้งหมดก่อนแก้ไข แล้วบันทึกเป็นรายการพร้อมข้อสันนิษฐานว่าแต่ละค่าน่าจะมีไว้เพื่ออะไร
• ทดสอบเปลี่ยนทีละตัวบน Staging แทนการรื้อทั้งหมดแล้วตั้งใหม่ตามมาตรฐานเอเจนซีทันที
• ตรวจว่ามีระบบเก่าของลูกค้าที่ยังพึ่งพา Header บางค่าอยู่หรือไม่ก่อนลบทิ้ง
• ยืนยันกับลูกค้าว่า Hosting เดิมเปลี่ยนมือหรือไม่ เพราะกระทบสิทธิ์เข้าถึง Header ระดับ Server

เช็กเมื่อเว็บลูกค้ามีหลายโดเมนย่อยที่ใช้งานร่วมกัน

• ขอแผนผังโดเมนและโดเมนย่อยทั้งหมดจากลูกค้าก่อนวางแผน Header
• ตรวจว่า frame-ancestors หรือ Content-Security-Policy ครอบคลุมความสัมพันธ์ระหว่างโดเมนย่อย เช่น ระบบสมาชิกหรือระบบจองคิว
• ทดสอบว่า Widget หรือ iframe ข้ามโดเมนย่อยยังทำงานได้หลังตั้ง Header ใหม่
• บันทึกความสัมพันธ์ระหว่างโดเมนย่อยไว้ในเอกสารส่งมอบ เพื่อให้ทีมอื่นในเอเจนซีเข้าใจภาพรวมได้

เช็กเมื่อลูกค้าใช้ระบบอีคอมเมิร์ซหรือระบบชำระเงินออนไลน์

• ตรวจว่า Content-Security-Policy อนุญาตโดเมนของผู้ให้บริการชำระเงินครบทุกจุดที่ระบบเรียกใช้ ทั้งหน้าชำระเงินและสคริปต์ยืนยันตัวตน
• ทดสอบขั้นตอนชำระเงินจริงแบบ end-to-end หลังเปลี่ยน Header ทุกครั้ง ไม่ใช่แค่ทดสอบว่าหน้าโหลดขึ้น
• ตรวจว่า frame-ancestors ไม่บล็อก iframe ของหน้าต่างยืนยันตัวตนที่ผู้ให้บริการชำระเงินฝังมา
• สอบถามผู้ให้บริการชำระเงินว่ามีข้อกำหนดเรื่อง Header เฉพาะที่ต้องปฏิบัติตามหรือไม่ก่อนตั้งค่า

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

วิธีเก็บบันทึกการตั้งค่าให้ทีมอื่นในเอเจนซีสืบทอดงานต่อได้

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

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

• ยืนยันเจ้าของการตัดสินใจเรื่อง Header และสิทธิ์เข้าถึงของเอเจนซีก่อนเริ่มงาน
• ตรวจว่าเว็บอยู่หลัง CDN หรือ Load Balancer ที่ควบคุมไม่ได้หรือไม่
• ไล่ตรวจ Header หลักทีละตัวตามตารางในบทความนี้
• ทดสอบฟอร์ม ระบบล็อกอิน ปลั๊กอิน และ Widget หลังเปลี่ยน Header ทุกครั้ง
• เขียนรายการ Header ที่ตั้งไว้พร้อมค่าจริงในรายงานส่งมอบ
• ระบุส่วนที่ต้องให้ Hosting หรือทีมไอทีลูกค้าดำเนินการต่อแยกจากส่วนที่เอเจนซีทำแล้ว
• ตกลงรอบ Re-test กับลูกค้าล่วงหน้าก่อนปิดงาน

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

• ใช้เช็กลิสต์เดียวกับทุกเว็บโดยไม่ปรับตามสแตกและปลั๊กอินที่ต่างกัน
• ข้ามการตรวจสิทธิ์เข้าถึงและ CDN จนไปพบปัญหาตอนใกล้ปิดงาน
• ตรวจ Header เฉพาะหน้าแรก ไม่ได้ทดสอบฟอร์มหรือระบบล็อกอินจริง
• ส่งมอบรายงานที่บอกว่าตั้ง Header ครบแต่ไม่ระบุค่าที่ใช้จริง
• ไม่ตกลงรอบ Re-test ทำให้ Header เสียหน้าที่ไปเงียบ ๆ หลังลูกค้าอัปเดตเว็บ

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• คู่มือ Website Security ทั้งหมดของ trusty
• วิธีวางระบบ HTTP Security Headers แบบเป็นขั้นตอนสำหรับเอเจนซี

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

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

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

ถ้าเว็บอยู่หลัง CDN ที่เอเจนซีเข้าไม่ถึง ต้องทำอย่างไร ควรระบุในรายงานว่า Header ส่วนนั้นต้องให้ทีมที่ดูแล CDN หรือ Load Balancer ของลูกค้าดำเนินการต่อ แทนที่จะข้ามไปเฉย ๆ

ทำไมต้องตกลงรอบ Re-test ล่วงหน้ากับลูกค้า เพราะ Header มักเสียหน้าที่ไปเงียบ ๆ หลังลูกค้าอัปเดตปลั๊กอินหรือย้าย Hosting การมีรอบ Re-test ที่ตกลงไว้ล่วงหน้าช่วยให้ทีมไม่ลืมกลับไปตรวจซ้ำ