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

เว็บไซต์ลูกค้าแต่ละรายที่เอเจนซีดูแลมักอยู่บนสแตกที่ต่างกัน บางรายใช้ WordPress กับปลั๊กอินสิบกว่าตัว บางรายใช้ Shopify กับ App จากตลาดกลาง การตั้ง Content Security Policy (CSP) แบบเดียวแล้วก็อปวางให้ทุกลูกค้าจึงเป็นสาเหตุอันดับต้นที่ทำให้เว็บไซต์พังหลังส่งมอบงาน เช็กลิสต์นี้เรียงตามลำดับที่ควรตรวจจริงก่อนเปิดใช้งาน CSP ให้ลูกค้าแต่ละราย

ใครควรเป็นเจ้าของ CSP บนเว็บไซต์ลูกค้า

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

เช็กลิสต์ก่อนเปิดใช้งาน CSP ให้ลูกค้าใหม่

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

เช็กลิสต์เฉพาะ WordPress, Shopify และ CMS อื่น

บน WordPress ปลั๊กอินแต่ละตัวมักโหลดสคริปต์จากโดเมนของผู้พัฒนาปลั๊กอินเอง การอัปเดตปลั๊กอินหรือเปลี่ยนธีมจึงมีโอกาสเพิ่มโดเมนใหม่ที่ CSP ยังไม่อนุญาตอยู่เสมอ ควรตรวจ CSP ทุกครั้งหลังอัปเดตปลั๊กอินหลักหรือเปลี่ยนธีม บน Shopify สคริปต์จาก App ในตลาดกลางมักฝังผ่าน Theme App Extension ซึ่งเอเจนซีควบคุม header ได้จำกัดกว่าระบบที่โฮสต์เอง ต้องตรวจกับเอกสารของ Shopify ว่า header ใดปรับได้จาก Theme และใดต้องพึ่งการตั้งค่าระดับแพลตฟอร์ม สำหรับ CMS ที่กำหนดเอง เอเจนซีมักควบคุม header ได้เต็มที่ที่สุด แต่ต้องมีเอกสารกำกับว่าใครแก้ config ได้บ้างเพื่อไม่ให้มีการเปลี่ยนแปลงที่ไม่มีใครรู้

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

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

เช็กลิสต์การรีเทสต์หลังลูกค้าอัปเดตเว็บไซต์

• ตรวจ Console ของเบราว์เซอร์ทุกครั้งหลังลูกค้าอัปเดตปลั๊กอิน ธีม หรือ App ใหม่
• เปรียบเทียบรายการโดเมนที่ CSP อนุญาตกับโดเมนที่ระบบใหม่เรียกใช้จริง
• ทดสอบฟีเจอร์ที่ลูกค้าใช้บ่อย เช่น ฟอร์มติดต่อและระบบแชต หลังทุกการเปลี่ยนแปลงใหญ่

เก็บบันทึกเป็นเอกสารกลางสำหรับพอร์ตลูกค้าหลายราย

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

การจัดการเมื่อเปลี่ยนทีมงานที่ดูแลลูกค้ารายนั้น

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

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

ใครควรเป็นเจ้าของ CSP บนเว็บไซต์ลูกค้า ขึ้นอยู่กับว่าใครดูแล Hosting ต่อเนื่องหลังส่งมอบงาน หากเอเจนซีดูแลต่อ เอเจนซีควรเป็นเจ้าของ หากลูกค้ามีทีม IT เอง เอเจนซีควรส่งมอบเอกสารพร้อมเหตุผลให้ครบ

ต้องตรวจ CSP ทุกครั้งที่อัปเดตปลั๊กอินหรือไม่ ควรตรวจโดยเฉพาะปลั๊กอินหลักที่โหลดสคริปต์จากภายนอก เพราะการอัปเดตมักเปลี่ยนโดเมนที่เรียกใช้โดยไม่แจ้งล่วงหน้า

ควรใส่อะไรในรายงานส่งมอบเรื่อง CSP ให้ลูกค้า ค่า directive ทั้งหมดที่ตั้งไว้พร้อมเหตุผลของแต่ละโดเมน วิธีทดสอบ และระบุจุดที่ต้องให้ฝั่ง Hosting ของลูกค้าดำเนินการต่อหากเกินขอบเขตที่เอเจนซีควบคุมได้

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

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

• สำรวจสคริปต์จากบุคคลที่สามทั้งหมดบนเว็บไซต์ลูกค้าก่อนเขียน directive
• ทดสอบด้วยโหมด Report-Only บนสภาพแวดล้อมทดสอบก่อนใช้งานจริงทุกครั้ง
• ตรวจ CSP เฉพาะสแตกของลูกค้า ไม่ว่าจะเป็น WordPress, Shopify หรือ CMS กำหนดเอง
• แยกให้ชัดว่ารายการใดอยู่ในรายงานส่งมอบลูกค้า และรายการใดต้องส่งต่อฝั่ง Hosting ของลูกค้า
• ตรวจ CSP ซ้ำหลังลูกค้าอัปเดตปลั๊กอิน ธีม หรือ App ทุกครั้ง
• บันทึกเหตุผลของทุกโดเมนที่อนุญาตไว้เป็นเอกสารอ้างอิงสำหรับทีมที่เข้ามาดูแลต่อ

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

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

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• คู่มือหลัก Content Security Policy (CSP)
• วิธี Audit CSP สำหรับเอเจนซี