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

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

บทความนี้เรียงขั้นตอนที่ทีมพัฒนาเว็บไซต์และฟรีแลนซ์ใช้ได้จริงเมื่อรับงานหลายเว็บพร้อมกัน ตั้งแต่การสำรวจสคริปต์ของลูกค้าแต่ละราย การเขียน policy แบบ Report-Only ไปจนถึงการระบุในรายงานส่งมอบงานว่าส่วนไหนเอเจนซีดูแลได้เอง และส่วนไหนต้องส่งต่อให้ฝ่ายโฮสติ้งหรือ IT ของลูกค้า

ก่อนเริ่มวาง CSP ต้องรู้ก่อนว่าใครเป็นเจ้าของ Header

Content Security Policy มักตั้งค่าที่ชั้นเซิร์ฟเวอร์หรือโฮสติ้ง เช่น ไฟล์ config ของ Apache/Nginx, กฎที่ CDN อย่าง Cloudflare หรือในโค้ดแอปพลิเคชันเอง คำถามแรกที่เอเจนซีต้องถามก่อนเขียน policy สักบรรทัดคือ ทีมมีสิทธิ์เข้าถึงจุดที่ตั้งค่า header จริงหรือไม่ ไม่ใช่แค่ว่าจะเขียน directive อะไร ภาพรวมของ header ความปลอดภัยตัวอื่นที่ควรตรวจคู่กันดูได้ที่คู่มือความปลอดภัยเว็บไซต์ของ trusty

เว็บที่เอเจนซีโฮสต์เองกับเว็บที่ลูกค้าโฮสต์เอง

ถ้าเอเจนซีเป็นคนดูแลโฮสติ้งเอง เช่น VPS หรือ Managed WordPress ภายใต้บัญชีของเอเจนซี งานนี้ทำได้ครบวงจรตั้งแต่เขียนจนถึงติดตั้งจริง แต่ถ้าลูกค้ามีฝ่าย IT ของตัวเองหรือใช้โฮสติ้งที่บริษัทอื่นดูแล เอเจนซีทำได้แค่ส่งมอบ policy ที่เขียนไว้ให้ฝ่ายนั้นนำไปตั้งค่า แล้วนัดทดสอบร่วมกันหลังติดตั้งจริงเท่านั้น

WordPress, Shopify และ CMS แบบ Custom ใครแก้ header ได้

บน WordPress ถ้าเอเจนซีคุมโฮสติ้งเองสามารถแก้ที่ไฟล์ config เซิร์ฟเวอร์ได้ตรง ๆ แต่ถ้าลูกค้าอยู่บน shared hosting ที่เอเจนซีไม่มีสิทธิ์แก้ config มักต้องพึ่งปลั๊กอินความปลอดภัยที่รองรับการตั้งค่า header แทน บน Shopify การควบคุม header ของหน้าร้านมีข้อจำกัดตามที่แพลตฟอร์มกำหนด โดยเฉพาะหน้า checkout ที่ Shopify เป็นผู้ดูแลเองนอกเหนือการควบคุมของธีมร้านค้า เอเจนซีที่รับงาน Shopify จึงควรตรวจเอกสารนักพัฒนาปัจจุบันของ Shopify ก่อนสัญญาว่าจะปรับ header ส่วนไหนได้จริง ส่วน CMS แบบ Custom หรือ Headless เช่นแอปที่ deploy ผ่าน pipeline ของเอเจนซีเอง มักตั้งค่า header ได้ตรงในไฟล์ config ของแพลตฟอร์ม deploy ซึ่งควบคุมได้เต็มที่ที่สุดในบรรดาสามแบบ

ขั้นตอนที่ 1 สำรวจสคริปต์และบริการภายนอกของเว็บลูกค้าก่อนเขียน policy

ก่อนเขียน directive อย่าง script-src, style-src, img-src, connect-src หรือ font-src เอเจนซีต้องมีรายการสคริปต์บุคคลที่สามของเว็บลูกค้ารายนั้นครบก่อน เช่น เครื่องมือวิเคราะห์ ปลั๊กอินแชท ตัวแสดงผลชำระเงินแบบ iframe ฟอนต์จากภายนอก และพิกเซลโฆษณา เพราะเว็บลูกค้าแต่ละรายใช้ชุดเครื่องมือไม่เหมือนกัน การนำ policy ของลูกค้ารายหนึ่งไปใช้ซ้ำกับอีกรายโดยไม่สำรวจใหม่มักบล็อกสคริปต์ที่ลูกค้าใหม่ใช้อยู่โดยไม่ตั้งใจ วิธีสำรวจที่ใช้ได้จริงคือเปิด Network tab ของเบราว์เซอร์ดูทุกโดเมนที่เว็บเรียกใช้ หรือเปิด CSP แบบ Report-Only ไว้ก่อนแล้วดูรายการที่ถูกรายงานว่าจะถูกบล็อก

ขั้นตอนที่ 2 เขียน CSP แบบ Report-Only ก่อนใช้งานจริงบน staging

Header ชื่อ Content-Security-Policy-Report-Only ให้เบราว์เซอร์รายงานสิ่งที่จะถูกบล็อกลง console โดยไม่บล็อกจริง เหมาะกับขั้นตอนแรกของงานเอเจนซีที่รับงานหลายเว็บพร้อมกัน เพราะทดสอบได้โดยไม่กระทบผู้ใช้จริงของลูกค้า ควรเปิดใช้บน staging หรือ dev environment ของโปรเจกต์นั้นก่อน แล้วเก็บผลรายงานไว้สักช่วงหนึ่งก่อนค่อยพิจารณาย้ายไป production หากทีมการตลาดของลูกค้าเพิ่มพิกเซลใหม่ระหว่างช่วงทดสอบ ต้องปรับ policy ตามและทดสอบซ้ำ เพราะ CSP เป็นงานที่ต้องดูแลต่อเนื่อง ไม่ใช่ตั้งครั้งเดียวจบ

ขั้นตอนที่ 3 ติดตั้ง Header จริงตามข้อจำกัดของแพลตฟอร์มลูกค้าแต่ละราย

วิธีติดตั้งจริงต่างกันตามสิทธิ์ที่เอเจนซีมี ถ้าเป็นโฮสติ้งที่เอเจนซีดูแลเองสามารถแก้ที่ config ของเว็บเซิร์ฟเวอร์หรือกฎที่ชั้น CDN ได้ตรง ถ้าลูกค้าอยู่บน WordPress shared hosting ที่ไม่มีสิทธิ์แก้ config มักต้องใช้ปลั๊กอินที่รองรับการตั้งค่า header แทน ส่วนเว็บที่ deploy ผ่านแพลตฟอร์มแบบ Jamstack เอเจนซีมักตั้งค่า header ได้ในไฟล์ config ของ pipeline deploy เอง ดูรายละเอียดเพิ่มเติมได้จากเช็กลิสต์ CSP สำหรับเอเจนซีที่รวมจุดตรวจตามแพลตฟอร์มไว้เป็นข้อ ๆ

ขั้นตอนที่ 4 ทดสอบ เปลี่ยนเป็น Enforce Mode และวางแผน Rollback

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

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

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

ทดสอบซ้ำทุกครั้งที่ลูกค้าอัปเดตเว็บหรือเพิ่มสคริปต์ใหม่

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

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

เอเจนซีต้องมีสิทธิ์เข้าถึงโฮสติ้งของลูกค้าเพื่อวาง CSP หรือไม่

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

ควรใช้ CSP แบบ Enforce หรือ Report-Only ก่อนสำหรับเว็บลูกค้าใหม่

เริ่มจาก Report-Only บน staging เสมอ เพราะให้เห็นรายการที่จะถูกบล็อกโดยไม่กระทบผู้ใช้จริง แล้วค่อยเปลี่ยนเป็น Enforce เมื่อผลทดสอบนิ่งแล้ว

ทำไม CSP เดียวกันใช้กับเว็บลูกค้าหลายรายไม่ได้

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

ควรทดสอบ CSP ซ้ำบ่อยแค่ไหนหลังส่งมอบงานให้ลูกค้า

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

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

• สำรวจสคริปต์และบริการภายนอกทั้งหมดของเว็บลูกค้าก่อนเขียน policy
• ระบุก่อนเริ่มงานว่าเอเจนซีมีสิทธิ์แก้ header บนโฮสติ้งของลูกค้าหรือไม่
• ทดสอบด้วย Content-Security-Policy-Report-Only บน staging ก่อนใช้งานจริงเสมอ
• เปลี่ยนเป็น Enforce mode หลังผ่านช่วงทดสอบและตรวจ console แล้วเท่านั้น
• แยกหัวข้อในรายงานว่าอะไรเอเจนซีทำเอง อะไรต้องส่งต่อให้ IT หรือโฮสติ้งของลูกค้า
• กำหนดรอบทดสอบซ้ำหลังลูกค้าอัปเดตปลั๊กอิน ธีม หรือสคริปต์การตลาด

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

• เปิดใช้ CSP แบบ Enforce ทันทีโดยไม่ผ่านโหมด Report-Only ทำให้เว็บลูกค้าใช้งานไม่ได้กลางดึก
• ใช้ policy เดียวกันซ้ำกับเว็บลูกค้าหลายรายโดยไม่สำรวจสคริปต์ของแต่ละเว็บใหม่
• ไม่ระบุในสัญญาหรือรายงานว่าใครรับผิดชอบดูแล header ต่อหลังส่งมอบงาน
• ลืมทดสอบซ้ำหลังลูกค้าเพิ่มพิกเซลการตลาดหรืออัปเดตปลั๊กอิน ทำให้ CSP บล็อกสคริปต์ใหม่แบบไม่รู้ตัว

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Content Security Policy Cheat Sheet