HTTP Security Headers คืออะไร คู่มือสำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์

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

บทความนี้พูดถึง HTTP Security Headers กลุ่มที่ไม่ใช่ Content-Security-Policy โดยตรง คือ Strict-Transport-Security (HSTS), X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy และ Permissions-Policy ซึ่งเป็นชุด Header พื้นฐานที่เอเจนซีและฟรีแลนซ์ทำเว็บไซต์ควรตั้งให้ลูกค้าแทบทุกโปรเจกต์ ไม่ว่าเว็บนั้นจะอยู่บน WordPress, Shopify หรือสแตกที่เขียนเอง

HTTP Security Headers คืออะไร และมีตัวไหนบ้างที่เอเจนซีต้องรู้จัก

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

Strict-Transport-Security (HSTS)

สั่งให้เบราว์เซอร์เชื่อมต่อเว็บนี้ผ่าน HTTPS เท่านั้นในครั้งต่อๆ ไป แม้ผู้ใช้จะพิมพ์ http:// เข้ามาเอง เบราว์เซอร์ก็จะเปลี่ยนเป็น https:// ให้อัตโนมัติโดยไม่ต้องรอ Redirect จากเซิร์ฟเวอร์ก่อน ข้อควรระวังสำหรับเอเจนซีคือค่า max-age ที่ตั้งไว้นานเกินไปจะย้อนกลับยาก หากลูกค้ามีซับโดเมนบางตัวที่ยังไม่รองรับ HTTPS เต็มรูปแบบ

X-Content-Type-Options

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

X-Frame-Options และ frame-ancestors

ควบคุมว่าเว็บของลูกค้าอนุญาตให้เว็บอื่นฝัง iframe เอาไปแสดงผลได้หรือไม่ ป้องกันเทคนิค clickjacking ที่หลอกให้ผู้ใช้กดปุ่มบนเว็บลูกค้าโดยไม่รู้ตัวผ่านเลเยอร์โปร่งใส สำหรับเอเจนซีที่ทำเว็บให้ลูกค้าหลายแบรนด์ ควรเช็กก่อนว่าลูกค้ามีความจำเป็นต้องฝังเว็บตัวเองในหน้าอื่น เช่น Micro-site หรือ iframe รายงานภายใน ก่อนตั้งค่าปิดทั้งหมด

Referrer-Policy

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

Permissions-Policy

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

ใครควรเป็นคนตั้งค่า Header ในงานเอเจนซี ทีมพัฒนา เอเจนซี หรือฝ่าย Hosting ของลูกค้า

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

แบบแรกคือเอเจนซีเป็นทั้งคนพัฒนาและดูแล Hosting เอง กรณีนี้ทีมพัฒนาตั้งค่าได้เต็มที่ที่ระดับเว็บเซิร์ฟเวอร์หรือ Edge Function แบบที่สองคือเอเจนซีพัฒนาแต่ลูกค้าเป็นคนเลือก Hosting เอง เช่น ลูกค้ามี Hosting เดิมอยู่แล้วและให้เอเจนซีอัปโหลดไฟล์เข้าไป กรณีนี้เอเจนซีมักตั้งค่าได้ผ่านไฟล์คอนฟิกของแอปพลิเคชัน แต่บาง Header ระดับ Transport เช่น HSTS ต้องพึ่งการตั้งค่าที่ตัว Hosting เอง แบบที่สามคือเอเจนซีรับงานเฉพาะดีไซน์หรือ Front-end แล้วทีม IT ของลูกค้าเป็นคนดูแล Backend/Server ทั้งหมด กรณีนี้เอเจนซีทำได้เพียงแนะนำและตรวจสอบ ไม่สามารถตั้งค่าเองได้

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

ข้อจำกัดตามสแตกของลูกค้า WordPress Shopify และ Hosting แบบกำหนดเอง

เว็บ WordPress ส่วนใหญ่ตั้งค่า Header ได้ผ่านไฟล์ .htaccess (บน Apache) หรือคอนฟิกของ Nginx ถ้าเอเจนซีมีสิทธิ์เข้าถึงระดับเซิร์ฟเวอร์ แต่ถ้าลูกค้าใช้ Hosting แบบ Managed WordPress บางเจ้าจะล็อกไม่ให้แก้ไฟล์คอนฟิกเซิร์ฟเวอร์ตรงๆ ต้องใช้ปลั๊กอินที่รองรับการตั้งค่า Header แทน ซึ่งควรเช็กก่อนว่าปลั๊กอินนั้นตั้งค่าได้ครบทุกตัวที่ต้องการหรือไม่

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

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

เว็บ WooCommerce ที่วางอยู่บนสแตก WordPress เดิม มีชั้นซับซ้อนเพิ่มขึ้นอีกชั้น เพราะปลั๊กอินตะกร้าสินค้าและเกตเวย์ชำระเงินมักฝัง iframe หรือสคริปต์จากผู้ให้บริการชำระเงินเข้ามาในหน้า Checkout เอเจนซีที่ตั้งค่า X-Frame-Options หรือ frame-ancestors แบบปิดทั้งเว็บโดยไม่เช็กหน้า Checkout ก่อน อาจทำให้กระบวนการชำระเงินของลูกค้าใช้งานไม่ได้ทันที ส่วนเว็บที่ทำด้วยเฟรมเวิร์กสมัยใหม่แล้ว Deploy ผ่านแพลตฟอร์ม Hosting ที่รองรับไฟล์คอนฟิกเฉพาะ เช่น การกำหนด Header ผ่านไฟล์ตั้งค่าโปรเจกต์ ก็มีข้อดีตรงที่ค่า Header จะถูกเก็บไว้ในซอร์สโค้ดเดียวกับเว็บ ทำให้เอเจนซีตรวจสอบย้อนหลังผ่านประวัติการแก้ไขไฟล์ได้ง่ายกว่าการตั้งค่าแยกอยู่ในแผงควบคุม Hosting ที่มองไม่เห็นประวัติ

การวางแผนเวลาและสัญญาเมื่อดูแล Header ให้ลูกค้าหลายราย

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

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

สิ่งที่ควรอยู่ในรายงานให้ลูกค้า และสิ่งที่ต้องส่งต่อให้ IT หรือ Hosting ของลูกค้าเอง

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

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

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

ลูกค้าที่ใช้ Shopify ตั้งค่า HTTP Security Headers เองได้ไหม

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

ต้องตั้งค่า Header ใหม่ทุกครั้งที่ลูกค้าอัปเดตปลั๊กอินหรือธีมไหม

ควรตรวจซ้ำหลังการอัปเดตใหญ่ทุกครั้ง เพราะปลั๊กอินหรือธีมใหม่บางตัวอาจเขียนทับคอนฟิก Header เดิม หรือเพิ่ม iframe/สคริปต์ที่ต้องปรับ Permissions-Policy ใหม่ให้สอดคล้องกัน

ถ้าลูกค้าไม่มีทีม IT เอง เอเจนซีควรทำอย่างไร

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

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

• ระบุในสโคปงานว่าเอเจนซีตั้งค่า Header ได้เองระดับไหน หรือต้องพึ่ง Hosting ของลูกค้า
• ตั้งค่า HSTS, X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy และ Permissions-Policy ให้ครบก่อนส่งมอบทุกโปรเจกต์ใหม่
• ตรวจสอบข้อจำกัดของแพลตฟอร์มลูกค้า เช่น Shopify หรือ Managed WordPress ก่อนสัญญาว่าจะตั้งค่าอะไรได้บ้าง
• คุยกับทีม Analytics หรือการตลาดของลูกค้าก่อนเปลี่ยนค่า Referrer-Policy ที่อาจกระทบการวัดผล
• แยกรายงานเป็นสองส่วน สิ่งที่เอเจนซีทำแล้ว กับสิ่งที่ต้องส่งต่อให้ IT/Hosting ของลูกค้า
• ตั้งรอบตรวจซ้ำหลังลูกค้าอัปเดตปลั๊กอิน ธีม หรือย้าย Hosting ใหม่

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

• ตั้งค่า HSTS ด้วย max-age ยาวเกินไปโดยไม่เช็กว่าซับโดเมนของลูกค้าทุกตัวรองรับ HTTPS แล้วหรือยัง
• ปิด X-Frame-Options ทั้งเว็บโดยไม่เช็กก่อนว่าลูกค้ามี Micro-site หรือรายงานภายในที่ต้องฝัง iframe
• สัญญากับลูกค้าว่าจะดูแล Header ให้ครบ ทั้งที่ Hosting จริงอยู่นอกสิทธิ์ที่เอเจนซีเข้าถึงได้
• ไม่ตรวจซ้ำหลังลูกค้าเปลี่ยนปลั๊กอินหรือธีมใหม่ ทำให้ค่าที่ตั้งไว้เดิมถูกเขียนทับโดยไม่รู้ตัว
• ส่งรายงานที่ปนกันระหว่างสิ่งที่ทำเสร็จแล้วกับสิ่งที่ยังรอ Hosting ของลูกค้า จนลูกค้าตีความผิดว่าทุกอย่างเสร็จแล้ว

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet
• OWASP Secure Headers Project