วิธี Audit HTTP Security Headers ของเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ พร้อม Evidence ที่ควรเก็บ

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

ความท้าทายเฉพาะของงานหลายลูกค้า

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

ขั้นตอน Audit สำหรับพอร์ตลูกค้าหลายราย

1. ตรวจ Response Header จริงของแต่ละไซต์

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

2. เทียบกับรายการ Header หลัก

ตรวจ Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy หรือ X-Frame-Options, Referrer-Policy และ Permissions-Policy ตามแนวทาง OWASP Secure Headers แล้วจดว่าแต่ละไซต์มีอะไรอยู่และขาดอะไร

3. แยกว่าอะไรแก้ได้ในระดับ CMS อะไรต้องพึ่ง Hosting

บนเว็บ WordPress หลาย Header ตั้งค่าผ่านปลั๊กอินความปลอดภัยหรือไฟล์ .htaccess ได้เลย แต่บางแพลตฟอร์มอย่าง Shopify จำกัดสิทธิ์แก้ Header ระดับเซิร์ฟเวอร์ ต้องอาศัยฟีเจอร์ที่แพลตฟอร์มเปิดให้เท่านั้น ส่วนเว็บที่อยู่บน Hosting ของลูกค้าเองซึ่งเอเจนซีไม่มีสิทธิ์ Root Access การแก้ไขต้องส่งคำแนะนำให้ฝ่าย IT หรือผู้ดูแล Hosting ของลูกค้าดำเนินการต่อ ระบุให้ชัดในรายงานว่าข้อไหนเป็นความรับผิดชอบของใคร

4. ตรวจซ้ำหลังลูกค้าอัปเดตเว็บทุกครั้ง

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

วิธีเก็บ Evidence และทำรายงานส่งลูกค้า

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

การเก็บผลตรวจให้ใช้ซ้ำได้กับลูกค้ารายต่อไป

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

การสื่อสารกับลูกค้าที่ใช้ Hosting ของตัวเอง

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

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

เอเจนซีต้องรับผิดชอบ Header ของ Hosting ที่ตัวเองไม่ได้ดูแลหรือไม่

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

ควร Audit Header ของลูกค้าแต่ละรายบ่อยแค่ไหน

อย่างน้อยทุกไตรมาส และทุกครั้งที่ทราบว่าลูกค้าอัปเดตปลั๊กอิน เปลี่ยนธีม หรือย้าย Hosting เพราะเหตุการณ์เหล่านี้มักทำให้ Header ที่เคยตั้งไว้เปลี่ยนแปลง

ทำไมเว็บ WordPress กับ Shopify ต้อง Audit ต่างกัน

WordPress มักแก้ Header ได้ผ่านปลั๊กอินหรือไฟล์ .htaccess โดยตรง ส่วน Shopify จำกัดสิทธิ์การแก้ Header ระดับเซิร์ฟเวอร์ ต้องอาศัยฟีเจอร์ที่แพลตฟอร์มเปิดให้เท่านั้น

ควรใส่อะไรในรายงานที่ส่งให้ลูกค้าที่ไม่ใช่สายเทคนิค

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

การผูก Audit เข้ากับกระบวนการรับงานใหม่

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

เครื่องมือที่ใช้ Audit และข้อจำกัดของแต่ละแบบ

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

อีกข้อจำกัดที่เอเจนซีมักมองข้ามคือเว็บลูกค้าที่อยู่หลัง CDN หรือ Reverse Proxy ผลตรวจจากเครื่องมือภายนอกอาจสะท้อนค่าที่ CDN ส่งกลับมา ไม่ใช่ค่าที่ Origin Server ตั้งไว้จริง ถ้า CDN มีการ Cache Header เก่าไว้ ผลตรวจอาจไม่ตรงกับสิ่งที่ทีมพัฒนาเพิ่งแก้ไปเมื่อไม่กี่ชั่วโมงก่อน วิธีที่ปลอดภัยกว่าคือตรวจซ้ำด้วย curl ผ่าน Origin โดยตรงหรือรอให้ Cache หมดอายุก่อนสรุปผล และควรตรวจจากมากกว่าหนึ่งตำแหน่งทางภูมิศาสตร์หากลูกค้าใช้ CDN ที่มี Edge หลายจุด เพราะบาง Edge อาจยังไม่ได้รับการอัปเดต Config ล่าสุด

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

การฝึกทีมภายในเอเจนซีให้ Audit ได้มาตรฐานเดียวกัน

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

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

การกำหนดราคาและขอบเขตบริการ Audit Header ให้ลูกค้าเข้าใจ

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

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

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

• ตรวจ Response Header จริงของทุกไซต์ลูกค้าด้วย curl หรือ Network tab
• เทียบกับรายการ Header หลักตามแนวทาง OWASP Secure Headers
• แยกรายการที่แก้ได้ระดับ CMS/ปลั๊กอิน กับรายการที่ต้องพึ่ง Hosting ของลูกค้า
• ตั้งขั้นตอนตรวจซ้ำทุกครั้งที่ลูกค้าอัปเดตปลั๊กอิน ธีม หรือย้าย Hosting
• เก็บ Evidence เป็นภาพหน้าจอพร้อมวันที่แยกตามไซต์
• ทำตารางรายงานสรุปที่ลูกค้าที่ไม่ใช่สายเทคนิคอ่านเข้าใจ
• ระบุขอบเขตความรับผิดชอบระหว่างเอเจนซีกับผู้ดูแล Hosting ในรายงาน

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

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

สรุป

การ Audit HTTP Security Headers สำหรับเอเจนซีต้องออกแบบให้ทำซ้ำได้กับลูกค้าหลายราย แยกความรับผิดชอบระหว่างสิ่งที่แก้ได้ระดับ CMS กับสิ่งที่ต้องพึ่ง Hosting ของลูกค้า และเก็บ Evidence เป็นรายงานที่ลูกค้าเข้าใจได้ง่าย เพื่อให้การส่งต่องานแก้ไขระหว่างเอเจนซีกับลูกค้าชัดเจน แต่ไม่ได้หมายความว่าเว็บจะปลอดภัยจากความเสี่ยงทุกรูปแบบ

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

• OWASP HTTP Security Response Headers Cheat Sheet
• คู่มือ Website Security ทั้งหมดของ trusty
• อัปเดต HTTP Security Headers ปี 2026 สำหรับเอเจนซี
• คู่มือ HTTPS และ TLS ที่เกี่ยวข้อง