เพิ่ม Content-Security-Policy โดยไม่ทำให้เว็บไซต์พัง

ผลสแกนความปลอดภัย รายงาน Lighthouse หรือผู้ให้บริการโฮสติ้งบอกว่าเว็บไซต์ของคุณไม่มี Content-Security-Policy วิธีแก้ดูเหมือนแค่ใส่ header เดียว คัดลอกนโยบายจากบล็อก ดีพลอย จบ แล้วฟอร์มจองก็โหลดไม่ขึ้น วิดเจ็ตแชตหายไป หรือที่แย่กว่านั้นคือไม่มีอะไรพังให้เห็น แต่ Google Ads หยุดนับ conversion เราเกือบทำแบบนี้กับเว็บไซต์ของเราเอง

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

Content-Security-Policy ทำอะไร

เป็น HTTP header ที่บอกเบราว์เซอร์ว่าหน้าเว็บโหลดสคริปต์ สไตล์ รูปภาพ ฟอนต์ เฟรม และการเชื่อมต่อจากแหล่งใดได้บ้าง ถ้าผู้โจมตีแทรกสคริปต์เข้ามาได้ (ผ่านปลั๊กอินที่ถูกแฮก สคริปต์ของบุคคลที่สามที่ถูกเจาะ หรือฟอร์มที่ไม่กรองข้อมูลที่รับเข้ามา) เบราว์เซอร์จะไม่รันสคริปต์นั้นและไม่ส่งข้อมูลไปยังเซิร์ฟเวอร์ที่ไม่รู้จัก เป็นหนึ่งในการป้องกันที่แข็งแรงที่สุดต่อ cross-site scripting และ card skimmer บนหน้าชำระเงิน

การไม่มี CSP เลยก็เป็นเรื่องปกติ ตอนที่เราสแกนร้านค้าออนไลน์ 1,482 ร้านก่อน Black Friday ประมาณหนึ่งในสามถูกแจ้งว่าไม่มี Content-Security-Policy

ทำไมการ "ใส่ header เฉยๆ" ทำให้เว็บพัง

นโยบายคือ whitelist ทุกอย่างที่คุณลืมใส่จะถูกบล็อก โดยผู้เข้าชมไม่เห็น มีเพียงบรรทัดเดียวใน console ของเบราว์เซอร์ ผู้ได้รับผลกระทบที่พบบ่อย:

• Tag วิเคราะห์และโฆษณา Google Analytics, Google Ads, Meta Pixel และ Microsoft Clarity โหลดจากหลาย host และมักเปลี่ยนเส้นทางต่อไปยัง host อื่นอีก
• เนื้อหาที่ฝังไว้ เครื่องมือจอง (Calendly), แผนที่, YouTube, วิดเจ็ตแชต และ iframe ชำระเงิน ต่างต้องมีแหล่ง frame และ script ของตัวเอง
• Inline script เฟรมเวิร์กและ CMS จำนวนมากใส่สคริปต์เล็กๆ ไว้ในหน้าโดยตรง นโยบายที่เข้มงวดจะบล็อกสคริปต์เหล่านี้ เว้นแต่คุณอนุญาต 'unsafe-inline' หรือเพิ่ม nonce (ค่าสุ่มต่อการโหลดหนึ่งครั้ง)
• หน้าที่ไม่มีใครทดสอบ หน้าติดต่อ หน้าขอบคุณหลังส่งฟอร์ม หน้าชำระเงิน หน้าเหล่านี้มักเป็นหน้าที่โหลดสคริปต์ conversion และสคริปต์ชำระเงิน

สิ่งที่เกิดขึ้นบนเว็บไซต์ของเราเอง

เว็บไซต์ของเรารันนโยบายแบบ report-only มาตั้งแต่เดือนกรกฎาคม 2026 เราสร้างเวอร์ชันแรกจาก network trace ของ production ทั้งหมด ไม่ใช่การเดา สิ่งเหล่านี้คือสิ่งที่ trace และรายงานจับได้ ทุกข้อจะทำให้บางอย่างพังถ้าเราบังคับใช้ตั้งแต่วันแรก:

• Ping conversion ของ Google Ads ทำงานเฉพาะบนหน้าติดต่อ การเช็กหน้าแรกไม่เห็นมันเลย ถ้าบังคับใช้โดยไม่มี host นี้ Ads จะไม่นับ conversion หลักของเรา คือคำขอติดต่อ
• Microsoft Clarity redirect ไปยัง host ของ Bing การอนุญาต *.clarity.ms ไม่พอ เพราะการซิงก์ ID ไปที่ c.bing.com
• พิกเซล remarketing ของ Ads ใช้โดเมนประเทศของผู้เข้าชม เช่น google.be หรือ google.co.th ไม่ใช่ google.com CSP ไม่มี wildcard สำหรับกรณีนี้ เราจึงระบุประเทศที่เราขายของ และยอมรับว่าข้อมูลกลุ่มเป้าหมายของประเทศอื่นจะขาดไปเล็กน้อย
• มี Ads host ตัวที่สองโผล่ขึ้นมาบนทุกหน้า เมื่อวันที่ 19 ตุลาคม 2026 การไล่ตรวจใหม่บนหกประเภทหน้าพบว่า pagead2.googlesyndication.com โหลดทุกหน้า ทั้งที่ไม่อยู่ใน trace เมื่อเดือนกรกฎาคม ผลสแกนความปลอดภัยของเราเองบอกว่านโยบายดูโอเคและเรา "แค่เปลี่ยนชื่อ header" ได้เลย ถ้าเราทำแบบนั้น conversion ของ Ads จะลดเหลือศูนย์โดยไม่มีข้อผิดพลาดให้เห็นสักอย่าง

บทเรียนเล็กๆ อีกสองข้อจากงานเดียวกัน Chrome ไม่สนใจ upgrade-insecure-requests ในนโยบายแบบ report-only และบันทึกข้อผิดพลาดใน console ซึ่ง Lighthouse จะนับเป็นคะแนนลบกับคุณ จึงควรเพิ่ม directive นี้ตอนสลับไปบังคับใช้เท่านั้น อีกข้อคือเฟรมเวิร์กของเรา (SvelteKit) เขียน inline hydration script ขณะที่โฮสติ้งของเรารองรับเฉพาะ header แบบคงที่ 'unsafe-inline' บน script จึงต้องคงไว้จนกว่าเราจะเพิ่ม nonce ต่อคำขอ นโยบายที่มีข้อประนีประนอมที่รู้และบันทึกไว้แล้ว ก็ยังบล็อกได้มากกว่าการไม่มีนโยบายเลย

วิธีเปิดใช้ CSP โดยไม่ทำให้อะไรพัง

1. ลิสต์สิ่งที่หน้าเว็บของคุณโหลด เปิด developer tools ของเบราว์เซอร์ แท็บ Network แล้วคลิกไล่ดูหน้าแรก หน้าเนื้อหา หน้าติดต่อหรือหน้าจอง หน้าชำระเงิน และหน้าขอบคุณ จด host ทุกตัว
2. เขียนนโยบายจากลิสต์นั้น เริ่มด้วย default-src 'self' แล้วเพิ่มแต่ละ host ใน directive ที่ต้องใช้: script-src, connect-src, img-src, frame-src, style-src, font-src
3. ดีพลอยแบบ report-only พร้อมการรายงาน ส่งเป็น Content-Security-Policy-Report-Only พร้อมทั้ง report-to (บวก Reporting-Endpoints header) และ report-uri แบบเก่า เบราว์เซอร์บางตัวยังไม่รองรับ report-to จึงใช้ทั้งสอง บันทึกเฉพาะ directive, host ที่ถูกบล็อก และ path ของหน้า เพราะ URL เต็มอาจมีข้อมูลของผู้เข้าชม
4. อ่านรายงานหนึ่งสัปดาห์ ผู้เข้าชมจริงใช้เบราว์เซอร์ ส่วนขยาย ประเทศ และหน้าที่ต่างจากคุณ เพิ่มสิ่งที่เป็นของคุณหรือของเครื่องมือที่คุณใช้ ส่วน noise จากส่วนขยายเบราว์เซอร์ให้ข้ามไป
5. เช็กซ้ำทุกครั้งที่แก้ tag เครื่องมือการตลาดเปลี่ยน host โดยไม่แจ้งคุณ ไล่ตรวจประเภทหน้าเดิมอีกครั้งหลังแก้ tag หรือนโยบายทุกครั้ง
6. สลับไปบังคับใช้ เปลี่ยนชื่อ header เป็น Content-Security-Policy คงการรายงานไว้ และดูรายงานกับตัวเลข conversion ของคุณในอีกไม่กี่วันถัดไป

สถานการณ์ของคุณ	สิ่งที่ต้องทำ
ผลสแกนบอก "ไม่มี CSP" แต่เว็บใช้งานได้ปกติ	เริ่ม report-only ภายในสัปดาห์นี้ อย่าคัดลอกนโยบายจากที่อื่น
คุณเพิ่ม CSP แล้วมีบางอย่างใช้ไม่ได้	เปลี่ยน header กลับเป็น report-only ทันที แล้วแก้นโยบายตามข้อผิดพลาดใน console
คุณรันโฆษณา Google Ads หรือ Meta	ทดสอบหน้าที่ conversion ทำงาน และเช็กตัวเลข conversion อีกไม่กี่วันหลังบังคับใช้
ร้านค้าออนไลน์ที่มีหน้าชำระเงิน	ทดสอบการชำระเงินจริง (ในโหมดทดสอบ) ขณะที่นโยบายทำงานอยู่ iframe ชำระเงินต้องมีแหล่งของตัวเอง
WordPress ที่มีปลั๊กอินเยอะ	เตรียมรับลิสต์ยาวๆ ปลั๊กอินที่แทรก inline script อาจบังคับให้ต้องคง 'unsafe-inline' ไว้ก่อน

ต้องการความช่วยเหลือ

เราตั้งค่า Content-Security-Policy อย่างปลอดภัย: trace จากหน้าเว็บจริงของคุณ ช่วง report-only พร้อม logging และสลับไปบังคับใช้เมื่อรายงานสะอาดแล้ว โดยเราเช็ก analytics และ conversion ของคุณทั้งก่อนและหลัง ส่งที่อยู่เว็บไซต์ของคุณมาให้เรา →

คุณทำเอเจนซี่อยู่ใช่ไหม เราทำงานนี้ภายใต้ชื่อของคุณ ภายใต้ NDA ดูว่าเราทำงานกับเอเจนซี่อย่างไร →

บทความที่เกี่ยวข้อง

• เราสแกนร้านค้าออนไลน์ 1,482 ร้านก่อน Black Friday: สิ่งที่เราพบ
• เว็บโดนแฮก ทำอย่างไร? คู่มือกู้ WordPress ในชั่วโมงแรก
• ชำระเงินไม่ได้ เว็บขายของ Shopify/WooCommerce: เช็กอะไรก่อน

แหล่งที่มา: MDN, Content-Security-Policy-Report-Only.