วิธีวางระบบ HTTP Security Headers สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

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

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

ขั้นตอนที่ 1: กำหนดเจ้าของ Header ก่อนเริ่มงานลูกค้าแต่ละราย

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

ขั้นตอนที่ 2: เลือกวิธีตั้งค่าตามสแตกของลูกค้าแต่ละราย

เว็บที่ทำบน WordPress ตั้งค่า Header ได้หลายทาง เช่น ผ่านไฟล์ตั้งค่าของ Web Server, ผ่านปลั๊กอินความปลอดภัยที่รองรับการตั้งค่า Header หรือผ่าน Panel ของ Hosting โดยตรง แต่ละทางมีข้อจำกัดต่างกัน ปลั๊กอินสะดวกแต่ผูกกับปลั๊กอินตัวนั้นตลอดไป ถ้าลูกค้าปิดใช้งานปลั๊กอินวันหนึ่ง Header ก็หายไปด้วยโดยไม่มีใครรู้ตัว

เว็บที่ทำบน Shopify ควบคุม Header ระดับ Server เองไม่ได้เพราะเป็นแพลตฟอร์ม SaaS ที่ปิดกล่อง เอเจนซีทำได้เพียงตรวจสอบว่าค่า Default ของแพลตฟอร์มครอบคลุมแค่ไหน และเน้นการควบคุมความเสี่ยงที่จุดอื่นแทน เช่น การจำกัดแอปเสริมที่ฝังสคริปต์นอกเหนือจากที่แพลตฟอร์มควบคุม ส่วนเว็บที่ทำเองด้วย Framework ยืดหยุ่นที่สุด เพราะตั้งค่า Header ได้ตรงที่โค้ดหรือ Reverse Proxy โดยตรง

ขั้นตอนที่ 3: ตั้งค่า Header หลักทีละตัวพร้อมเหตุผลที่ลูกค้าเข้าใจได้

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

ตัวอย่างลำดับที่แนะนำ

• X-Content-Type-Options: nosniff
• Referrer-Policy: กำหนดตามระดับข้อมูลที่ต้องการส่งออกไปยังปลายทาง
• Strict-Transport-Security: หลังยืนยันแล้วว่าทุกหน้าใช้ HTTPS ครบ
• Content-Security-Policy: เริ่มจากโหมดที่ยังไม่บล็อกจริงเพื่อเก็บรายชื่อโดเมนก่อน
• X-Frame-Options หรือ frame-ancestors: ตั้งตามจริงว่าหน้าเว็บถูกฝังใน iframe จากที่อื่นหรือไม่

ขั้นตอนที่ 4: ทดสอบบน Staging ก่อนส่งมอบเสมอ

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

ขั้นตอนที่ 5: เขียนรายงานส่งมอบแยกส่วนที่ทำแล้วกับส่วนที่ต้องให้ลูกค้าทำต่อ

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

ขั้นตอนที่ 6: วางแผน Re-test หลังลูกค้าอัปเดตธีม ปลั๊กอิน หรือย้าย Hosting

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

เมื่อเว็บลูกค้าอยู่หลัง CDN หรือ Load Balancer ที่เอเจนซีเข้าไม่ถึง

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

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

การสื่อสารกับลูกค้าที่ไม่มีพื้นฐานด้านเทคนิค

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

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

การจัดการ Header เมื่อรับงานต่อจากทีมเดิมที่ทำเว็บไว้ก่อนหน้า

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

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

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

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

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

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

• ตกลงกับลูกค้าให้ชัดว่าเอเจนซีเป็นเจ้าของ Header ระดับใด และลูกค้า/Hosting ต้องดูแลส่วนไหนเอง
• ตรวจสแตกของลูกค้าแต่ละรายก่อนเลือกวิธีตั้งค่า Header ให้เหมาะกับ WordPress, Shopify หรือ Framework ที่ทำเอง
• เริ่มตั้งค่า Header ที่กระทบน้อยก่อน แล้วค่อยไปที่ Content-Security-Policy และ frame-ancestors
• ทดสอบเส้นทางหลักของเว็บบน Staging ก่อนย้ายค่าไป Production ทุกครั้ง
• เขียนรายงานส่งมอบแยกส่วนที่ทำแล้วกับส่วนที่ต้องให้ลูกค้าหรือ Hosting ดำเนินการต่อ
• ตกลงรอบ Re-test กับลูกค้าล่วงหน้าหลังมี Major Update ของ CMS หรือย้าย Hosting
• เก็บบันทึกว่า Header แต่ละตัวตั้งไว้ที่ไหน เพื่อให้ทีมอื่นในเอเจนซีดูแลต่อได้

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

• ตั้ง Header เดียวกันกับทุกเว็บลูกค้าโดยไม่ตรวจสแตกและปลั๊กอินที่ต่างกัน
• เปลี่ยน Header บน Production ตรง ๆ โดยไม่ผ่าน Staging ก่อน
• ไม่แจ้งลูกค้าว่า Header บางตัวต้องให้ Hosting หรือทีมไอทีของลูกค้าดำเนินการต่อ
• ส่งมอบงานแล้วไม่วางรอบ Re-test ทำให้ Header เสียหน้าที่ไปเงียบ ๆ หลังลูกค้าอัปเดตปลั๊กอิน
• เข้าใจว่าตั้ง Header แล้วเท่ากับเว็บลูกค้าปลอดภัยครบทุกด้าน

สรุป

การวางระบบ HTTP Security Headers สำหรับเอเจนซีต่างจากการทำเว็บของตัวเองตรงที่ต้องจัดการหลายสแตกพร้อมกัน และต้องสื่อสารขอบเขตงานกับลูกค้าให้ชัดตั้งแต่ต้น ทั้งเรื่องเจ้าของการตัดสินใจ วิธีตั้งค่าตามแพลตฟอร์ม การทดสอบก่อนส่งมอบ และรอบ Re-test หลังลูกค้าอัปเดตเว็บ ขั้นตอนเหล่านี้ช่วยลดปัญหา Header พังเงียบ ๆ ที่มักเกิดจากการเปลี่ยนแปลงฝั่งลูกค้าที่เอเจนซีควบคุมไม่ได้

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

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

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

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

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

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

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