วิธี Audit Content Security Policy (CSP) ของเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ พร้อม Evidence ที่ควรเก็บ

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

วิธีตรวจว่าเว็บไซต์ลูกค้ามี CSP อยู่แล้วหรือไม่

เริ่มจากเปิด Developer Tools ของเบราว์เซอร์ ไปที่แท็บ Network โหลดหน้าเว็บของลูกค้าใหม่ แล้วดู Response Header ของคำขอหลักที่โหลดหน้า HTML หากมี header ชื่อ Content-Security-Policy หรือ Content-Security-Policy-Report-Only ปรากฏอยู่ แปลว่าเว็บไซต์มีการตั้งค่าอยู่แล้ว ควรตรวจซ้ำอย่างน้อยสามหน้าที่ต่างประเภทกัน เช่น หน้าแรก หน้าฟอร์มติดต่อ และหน้าบทความ เพราะบางระบบตั้ง header เฉพาะบางเส้นทางเท่านั้น ไม่ได้ครอบคลุมทั้งเว็บไซต์ หากไม่พบ header เลยในทุกหน้าที่ตรวจ ให้บันทึกไว้เป็นข้อเท็จจริงว่าเว็บไซต์ยังไม่มี CSP ไม่ใช่ข้อสันนิษฐาน

อ่านค่า Header ที่ตรวจเจอ แปลว่าอะไร

เมื่อพบ header แล้ว ให้แยกอ่านทีละ directive เช่น default-src กำหนดค่าเริ่มต้นของทุกประเภททรัพยากรที่ยังไม่มี directive เฉพาะ script-src ควบคุมว่าสคริปต์โหลดจากที่ใดได้บ้าง frame-src และ form-action ควบคุมเรื่อง iframe และปลายทางของฟอร์ม การอ่านค่าที่พบต้องระวังกรณีที่ใช้ 'unsafe-inline' หรือ 'unsafe-eval' อยู่ ซึ่งแม้จะทำให้เว็บไซต์ทำงานได้ง่ายแต่ลดความหมายของการมี CSP ลงมาก ควรบันทึกไว้เป็นข้อสังเกตในรายงานว่าค่านี้ยังเปิดกว้างอยู่ ไม่ใช่ปัญหาที่ต้องแก้ทันที แต่เป็นจุดที่ควรพิจารณาปรับในอนาคต

เก็บ Evidence อะไรบ้างระหว่าง Audit

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

Audit แยกตามสแตกของลูกค้า

บน WordPress ให้ตรวจเพิ่มว่ามีปลั๊กอินด้านความปลอดภัยตัวใดกำลังควบคุม header อยู่หรือไม่ เพราะบางปลั๊กอินตั้ง CSP ให้อัตโนมัติโดยเจ้าของเว็บไซต์ไม่รู้ตัว การไปตั้งค่าซ้ำที่ระดับ Server อาจเกิดการชนกัน บน Shopify ต้องตรวจว่า header ที่พบมาจากการตั้งค่าของ Shopify เองหรือจาก App ที่ติดตั้งเพิ่ม เพราะสิทธิ์ในการแก้ไขต่างกัน สำหรับ CMS ที่กำหนดเองหรือเว็บไซต์ที่พัฒนาแบบ Custom ให้ตรวจที่ระดับ Web Server หรือ Reverse Proxy เพราะ header มักถูกตั้งที่ชั้นนั้นแทนที่จะเป็นโค้ดแอปพลิเคชันโดยตรง

ผลตรวจแบบไหนต้องส่งกลับไปยังทีมพัฒนาหรือ Hosting ของลูกค้า

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

โครงสร้างรายงานผลตรวจที่ส่งมอบให้ลูกค้า

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

เมื่อ Audit หลายเว็บไซต์พร้อมกัน ควรจัดลำดับผลอย่างไร

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

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

จะรู้ได้อย่างไรว่าเว็บไซต์ลูกค้ามี CSP อยู่แล้วหรือไม่ เปิด Developer Tools ของเบราว์เซอร์ ไปที่แท็บ Network แล้วตรวจ Response Header ของหน้าเว็บว่ามี Content-Security-Policy ปรากฏอยู่หรือไม่ ควรตรวจหลายหน้าไม่ใช่แค่หน้าแรก

ควรเก็บ Evidence อะไรบ้างระหว่างการ Audit CSP ภาพหน้าจอ Response Header จริงพร้อมวันที่ตรวจ รายการ error จาก Console หากมี และรายการโดเมนที่เว็บไซต์เรียกใช้จริงเทียบกับโดเมนที่ CSP อนุญาต

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

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

เครื่องมือที่ใช้ระหว่าง Audit และข้อจำกัดของแต่ละแบบ

เครื่องมือตรวจ Header แบบออนไลน์ที่ยิง Request จากภายนอกช่วยให้เห็นภาพรวมได้เร็ว แต่มีข้อจำกัดตรงที่ไม่เห็นพฤติกรรมจริงของผู้ใช้ที่ล็อกอินแล้วหรือหน้าที่ต้องกรอกข้อมูลก่อนถึงจะโหลด ดังนั้นการ Audit ที่ครบถ้วนควรผสมทั้งการตรวจจากภายนอกด้วยเครื่องมือ และการตรวจด้วยมือผ่าน Developer Tools ขณะใช้งานเว็บไซต์จริงในสถานะที่ล็อกอินแล้ว โดยเฉพาะเว็บไซต์ที่มีระบบสมาชิกหรือแดชบอร์ดส่วนตัวซึ่งมักมีสคริปต์และ iframe เพิ่มเติมที่ไม่ปรากฏในหน้าสาธารณะทั่วไป การพึ่งเครื่องมืออัตโนมัติเพียงอย่างเดียวจึงเสี่ยงต่อการมองข้ามความเสี่ยงในส่วนที่สำคัญที่สุดของเว็บไซต์

ความถี่ของการ Audit ซ้ำหลังส่งรายงานครั้งแรก

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

การจัดเก็บไฟล์ Evidence ให้ใช้งานซ้ำได้ในระยะยาว

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

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

ความแตกต่างระหว่าง Audit ครั้งแรกกับ Audit ต่อเนื่องหลังลูกค้าเป็นลูกค้าประจำ

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

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

การให้คะแนนความเสี่ยงเพื่อจัดลำดับความสำคัญของรายการที่พบ

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

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

• ตรวจ Response Header ผ่าน Developer Tools อย่างน้อยสามหน้าที่ต่างประเภทกันของเว็บไซต์ลูกค้า
• บันทึกว่าเว็บไซต์มี CSP อยู่แล้วหรือไม่ พร้อมภาพหน้าจอเป็นหลักฐาน
• อ่านและแปลความหมายของแต่ละ directive ที่พบ รวมถึงสังเกตการใช้ unsafe-inline หรือ unsafe-eval
• เปรียบเทียบโดเมนที่เว็บไซต์เรียกใช้จริงกับโดเมนที่ CSP อนุญาตไว้
• ระบุในรายงานว่าปัญหาใดเอเจนซีแก้ไขได้เอง และปัญหาใดต้องส่งต่อฝั่ง Hosting ของลูกค้า
• ตรวจแหล่งที่มาของ CSP ว่าถูกตั้งจากปลั๊กอิน แพลตฟอร์ม หรือระดับ Server เพื่อวางแผนแก้ไขให้ถูกจุด

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

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

สรุป

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

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

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