วิธี Audit Content Security Policy (CSP) ของร้านค้าออนไลน์ พร้อม Evidence ที่ควรเก็บ

ทีมการตลาดเปิดแคมเปญโฆษณาใหม่ ติดตั้ง Pixel ตัวที่สี่ลงในหน้าชำระเงิน แล้วปุ่ม “ยืนยันการสั่งซื้อ” ก็เงียบไปทั้งวันโดยไม่มี Error ขึ้นบนหน้าจอให้เห็น ทีมสงสัยว่าเซิร์ฟเวอร์ล่มหรือระบบตะกร้าเสีย แต่พอเปิด Console ของเบราว์เซอร์กลับพบข้อความ “Refused to load the script because it violates the following Content Security Policy directive” เต็มไปหมด นี่คืออาการคลาสสิกของร้านค้าออนไลน์ที่มี Content Security Policy (CSP) ตั้งไว้ตั้งแต่ตอนสร้างเว็บ แล้วไม่มีใครทบทวนอีกเลยจนกระทั่ง Script ตัวใหม่ถูกบล็อกแบบเงียบ ๆ

บทความนี้เป็นแนวทาง Audit ว่าร้านค้ามี CSP อยู่จริงหรือไม่ ครอบคลุมส่วนไหนบ้าง มีจุดไหนที่มักชนกับ Payment Gateway หรือ Marketing Pixel และควรเก็บ Evidence อะไรไว้ระหว่างตรวจ เพื่อให้คุยกับทีมพัฒนาได้ตรงจุดโดยไม่ต้องเดา

Content Security Policy คืออะไรและทำไมทีม E-commerce ต้องเกี่ยวข้อง

CSP เป็น HTTP Header ที่บอกเบราว์เซอร์ว่าอนุญาตให้โหลด Script, Style, Image, Frame หรือเชื่อมต่อ API จากโดเมนไหนได้บ้าง เป้าหมายหลักคือลดความเสี่ยงจากการถูกฝัง Script แปลกปลอมผ่านช่องโหว่ประเภท Cross-Site Scripting ซึ่งในบริบทร้านค้าออนไลน์ Script แปลกปลอมที่ทำงานอยู่บนหน้าชำระเงินสามารถดักข้อมูลบัตรระหว่างที่ลูกค้ากำลังกรอกได้ CSP จึงไม่ใช่แค่เรื่องของทีมพัฒนา แต่เกี่ยวข้องกับทีมการตลาดโดยตรง เพราะทุกครั้งที่เพิ่ม Tag Manager, Pixel โฆษณา หรือ Widget รีวิวสินค้าตัวใหม่ นั่นคือการเพิ่มโดเมนที่ CSP ต้องอนุญาตให้โหลดเพิ่มขึ้นอีกหนึ่งรายการ

วิธีตรวจสอบว่าร้านมี CSP อยู่แล้วหรือยัง

เริ่มจากเปิด DevTools ของเบราว์เซอร์ ไปที่แท็บ Network แล้วโหลดหน้าแรกของร้านใหม่ คลิกที่ Request แรกสุดแล้วดูใน Response Headers ว่ามีบรรทัด Content-Security-Policy หรือไม่ ถ้ามี ให้บันทึกค่าทั้งหมดเก็บไว้เป็นหลักฐานตั้งต้น บางร้านตั้งค่าผ่าน Header ชื่อ Content-Security-Policy-Report-Only แทน ซึ่งหมายความว่ายังอยู่ในโหมดทดสอบ ไม่ได้บล็อกจริง ต้องแยกให้ออกว่าร้านของตัวเองอยู่โหมดไหน

ขั้นต่อไปคือไล่ดูแท็บ Console ของทุกหน้าที่สำคัญ ไม่ใช่แค่หน้าแรก ได้แก่ หน้าแรก หน้ารายละเอียดสินค้า หน้าตะกร้า และหน้าชำระเงิน เพราะแต่ละหน้ามักโหลด Script คนละชุด ข้อความ error ที่ต้องมองหาจะขึ้นต้นด้วยคำว่า “Refused to load”, “Refused to connect” หรือ “violates the following Content Security Policy directive” เครื่องมือตรวจ Header ออนไลน์ก็ช่วยดูภาพรวมได้เร็ว แต่ผลจากเครื่องมืออัตโนมัติเหล่านี้ตรวจได้เฉพาะว่ามี Header อยู่หรือไม่และรูปแบบถูกต้องหรือไม่เท่านั้น ไม่ได้บอกว่า Policy ที่ตั้งไว้เหมาะกับการใช้งานจริงของร้านหรือเปล่า ส่วนนั้นต้องมาจากการไล่ดู Console ด้วยตาเอง

จุดที่ CSP มักชนกับ Checkout และ Payment Gateway

หน้าชำระเงินของร้านค้าออนไลน์ไทยส่วนใหญ่ต้องฝัง Widget หรือ iframe จากผู้ให้บริการ Payment Gateway เช่น 2C2P, Omise, GB Prime Pay หรือ QR Code สำหรับพร้อมเพย์ ถ้า CSP ไม่ได้อนุญาตโดเมนของผู้ให้บริการเหล่านี้ไว้ใน directive frame-src หรือ child-src กล่อง iframe สำหรับกรอกเลขบัตรจะขึ้นเป็นหน้าขาวหรือไม่แสดงผลเลย และถ้า JavaScript ของหน้าชำระเงินต้องยิง Request ไปยัง API ของ Payment Gateway โดยตรงเพื่อทำ Tokenization บัตร ก็ต้องอนุญาตโดเมนนั้นไว้ใน connect-src ด้วย ไม่ใช่แค่ script-src เพียงอย่างเดียว

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

วิธีเก็บ Evidence ระหว่าง Audit

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

จุดที่ CSP มักชนกับ Marketing Pixel และ Tag Manager

ฝั่ง Marketing ก็มีปัญหาคล้ายกัน script-src ต้องอนุญาตโดเมนอย่าง googletagmanager.com, google-analytics.com, connect.facebook.net หรือ analytics.tiktok.com ตามที่ร้านใช้งานจริง ส่วน img-src ต้องอนุญาตโดเมนที่ใช้ยิง Pixel แบบรูปภาพขนาด 1x1 เช่น facebook.com/tr หรือโดเมนที่ใช้วัด Conversion ของแพลตฟอร์มโฆษณาต่าง ๆ ปัญหาที่เกิดขึ้นบ่อยที่สุดคือทีมการตลาดเพิ่ม Tag ใหม่ผ่าน Google Tag Manager ได้เองโดยไม่ต้องแตะโค้ดเว็บไซต์เลย ทำให้ลืมไปว่าต้องแจ้งทีมพัฒนาให้เพิ่มโดเมนนั้นลง Allowlist ของ CSP ก่อน ผลคือ Script ถูกบล็อกแบบเงียบ ไม่มี error ที่ผู้ใช้ทั่วไปเห็น แต่ Conversion ที่ควรถูกนับกลับหายไปโดยไม่มีใครรู้ตัว จนกว่าจะมาเทียบยอดขายจริงกับยอดที่ระบบโฆษณารายงาน

แนวทางที่ลดปัญหานี้ได้คือกำหนด Workflow ให้ชัดว่าทุกครั้งที่ทีมการตลาดจะเพิ่ม Tag ใหม่ผ่าน Tag Manager ต้องแจ้งรายชื่อโดเมนที่ Script ตัวนั้นเรียกใช้ให้ทีมพัฒนาทราบล่วงหน้า เพื่อเพิ่มลง Allowlist ก่อน Publish จริง ไม่ใช่แจ้งหลังจากพบว่า Conversion หายไปแล้ว

ใช้ Content-Security-Policy-Report-Only ก่อนบังคับใช้จริง

ก่อนเปลี่ยน Policy ที่มีผลกระทบต่อหน้าชำระเงิน ควรทดสอบผ่าน Header ชื่อ Content-Security-Policy-Report-Only ก่อน Header ตัวนี้จะบันทึก Violation ที่เกิดขึ้นจริงโดยไม่บล็อกการทำงานจริง เหมาะกับร้านค้าออนไลน์ที่รับความเสี่ยงหน้าชำระเงินล่มไม่ได้แม้แต่นาทีเดียว ควรตั้งค่า report-uri หรือ report-to ให้ส่งรายงาน Violation เข้ามารวมไว้ที่จุดเดียว แล้วเปิดใช้งานในช่วงที่ไม่มีแคมเปญใหญ่ ปล่อยให้เก็บข้อมูลอย่างน้อยหนึ่งรอบธุรกิจ เช่น ครอบคลุมทั้งวันธรรมดาและวันที่มีแคมเปญโปรโมชัน ก่อนตัดสินใจย้ายไปใช้โหมดบังคับใช้จริงบน Production

การทดสอบ CSP ในช่วงแคมเปญยอดขายสูง

ช่วงแคมเปญโปรโมชันใหญ่ เช่นเทศกาลลดราคาประจำปี เป็นช่วงที่ร้านค้าออนไลน์มักเพิ่ม Landing Page ใหม่ ติดตั้ง Live Chat ตัวใหม่ หรือเปิด Affiliate Tracker เพิ่มเพื่อวัดผลแคมเปญ ทุก Script ที่เพิ่มเข้ามาในช่วงนี้มีโอกาสถูก CSP บล็อกได้เหมือนกัน ทีมที่มีประสบการณ์มักวางแผนล่วงหน้าอย่างน้อยหนึ่งสัปดาห์ก่อนแคมเปญเริ่ม โดยทดสอบ Landing Page และ Widget ใหม่ทั้งหมดบน Staging พร้อม CSP เวอร์ชันที่จะใช้จริง แทนที่จะเพิ่ม Script เข้าไปบน Production ตรง ๆ ในวันแคมเปญ เพราะถ้าเกิดปัญหาในวันที่มีลูกค้าเข้าเว็บพร้อมกันจำนวนมาก การแก้ไขจะทำได้ยากกว่าปกติมาก

อีกจุดที่มักถูกมองข้ามคือ Live Chat และ Affiliate Tracker ซึ่งบางเจ้าโหลด Script จากหลายโดเมนพร้อมกัน ทั้งโดเมนหลักของผู้ให้บริการและโดเมนย่อยสำหรับเก็บสถิติ หากตรวจแค่โดเมนหลักแล้วเพิ่มลง Allowlist แต่ลืมโดเมนย่อย ก็ยังเกิดปัญหา Script ถูกบล็อกบางส่วนอยู่ดี วิธีที่ปลอดภัยกว่าคือขอเอกสารรายชื่อโดเมนทั้งหมดที่ผู้ให้บริการแต่ละรายใช้งานจริงจากทีมสนับสนุนของเขาโดยตรง แทนการเดาเองจาก Console เพียงอย่างเดียว

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

• ตรวจ Response Header ของหน้าแรก หน้าสินค้า หน้าตะกร้า และหน้าชำระเงินว่ามี Content-Security-Policy จริงหรือไม่
• ไล่ดู Console ของทุกหน้าสำคัญหา error ที่ขึ้นต้นด้วย “Refused to”
• ทำรายชื่อโดเมน Payment Gateway และ Marketing Pixel ที่ร้านใช้จริงทั้งหมด เทียบกับ Allowlist ปัจจุบัน
• ทดสอบ Tag หรือ Script ใหม่ใน Report-Only Mode ก่อน Publish จริงบน Production
• เก็บภาพหน้าจอ Console error พร้อมวันที่และโดเมนที่ถูกบล็อกทุกครั้งที่พบปัญหา
• นัดคุยกับทีมพัฒนาเป็นรอบ เช่นทุกไตรมาส เพื่อทบทวน Allowlist ที่ไม่ได้ใช้งานแล้วออก
• ตรวจสอบ frame-src และ connect-src แยกจาก script-src เพราะ Payment Gateway มักต้องใช้ทั้งสาม directive พร้อมกัน

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

• เพิ่ม Pixel หรือ Tag ใหม่ผ่าน Google Tag Manager โดยไม่แจ้งทีมพัฒนาให้ปรับ CSP ก่อน
• ใช้เครื่องหมาย wildcard ครอบคลุมทั้งโดเมนแทนการระบุ Subdomain ที่จำเป็นจริง เพราะรีบแก้ปัญหาเฉพาะหน้า
• ปล่อย CSP ไว้ในโหมด Report-Only ตลอดโดยไม่เคยเปิดดูรายงานหรือย้ายไปโหมดบังคับใช้จริง
• ลบ Allowlist เก่าที่ Agency รายก่อนทิ้งไว้โดยไม่ตรวจก่อนว่ายังมีระบบใดใช้อยู่
• ทดสอบเฉพาะหน้าจอ Desktop โดยไม่ตรวจหน้าชำระเงินฝั่งมือถือ ซึ่งบางร้านใช้ Payment Widget คนละตัวกัน

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

Content Security Policy กับ HTTPS ต่างกันอย่างไร HTTPS ทำหน้าที่เข้ารหัสข้อมูลระหว่างเดินทางจากเบราว์เซอร์ไปเซิร์ฟเวอร์ ส่วน CSP ควบคุมว่าเบราว์เซอร์อนุญาตให้โหลด Script, Style หรือเชื่อมต่อไปยังโดเมนไหนได้บ้าง เป็นคนละชั้นการป้องกันที่ควรใช้ร่วมกัน ดูรายละเอียดเพิ่มเติมได้ที่ คู่มือ HTTPS และ TLS สำหรับเว็บไซต์

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

ควรใช้ Enforce Mode หรือ Report-Only Mode ก่อน สำหรับร้านค้าออนไลน์ที่มีหน้าชำระเงินเป็นหัวใจของธุรกิจ แนะนำให้เริ่มจาก Report-Only Mode เสมอ เก็บข้อมูล Violation อย่างน้อยหนึ่งรอบธุรกิจก่อน แล้วค่อยย้ายไป Enforce Mode เมื่อมั่นใจว่า Allowlist ครอบคลุมของจริงที่ใช้งานหมดแล้ว

ทีมการตลาดต้องรู้เรื่อง CSP มากแค่ไหน ทีมการตลาดไม่จำเป็นต้องเขียน Policy เองได้ แต่ควรรู้ว่า Pixel หรือ Tag ที่ตัวเองติดตั้งเรียกใช้โดเมนอะไรบ้าง เพื่อแจ้งทีมพัฒนาให้เพิ่มลง Allowlist ก่อน Publish ทุกครั้ง

ตรวจ CSP เองได้โดยไม่ต้องพึ่งทีมพัฒนาหรือไม่ ตรวจสอบเบื้องต้นผ่าน DevTools และ Console ทำได้เอง แต่การแก้ไขค่า Header จริงบนเซิร์ฟเวอร์ยังต้องผ่านทีมพัฒนาหรือทีมที่ดูแลโครงสร้างเว็บไซต์เสมอ ดูแนวทางเพิ่มเติมได้ที่ เช็กลิสต์ HTTP Security Headers สำหรับร้านค้าออนไลน์

สรุป

การ Audit CSP ของร้านค้าออนไลน์เริ่มจากตรวจว่ามี Header อยู่จริงหรือไม่ ไล่ดู Console หา Script ที่ถูกบล็อก แล้วทำรายชื่อโดเมนของ Payment Gateway และ Marketing Pixel ทั้งหมดเทียบกับ Allowlist ปัจจุบัน ก่อนทดสอบการเปลี่ยนแปลงผ่าน Report-Only Mode เสมอเพื่อไม่ให้กระทบยอดขาย เก็บ Evidence ทุกครั้งที่พบปัญหาเพื่อให้คุยกับทีมพัฒนาได้ตรงจุดและรวดเร็วขึ้น

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

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