คู่มือ Content Security Policy Generator: ป้องกัน XSS ตั้งแต่ต้นทาง
เรียนรู้วิธีใช้ Content Security Policy (CSP) Generator ฟรี เพื่อสร้าง CSP header ที่แข็งแรง บล็อก XSS, injection และการดึงข้อมูลออกจากระบบได้ในไม่กี่นาที
Table of Contents
คู่มือ Content Security Policy Generator: ป้องกัน XSS ตั้งแต่ต้นทาง
Cross-Site Scripting (XSS) ยังคงเป็นหนึ่งในช่องโหว่ที่พบบ่อยและอันตรายที่สุดของเว็บแอปพลิเคชันสมัยใหม่ ไม่ว่าจะเป็นการ inject script ที่ไม่พึงประสงค์ การขโมย session cookie หรือการดึงข้อมูลผู้ใช้ส่งไปยังเซิร์ฟเวอร์ของผู้โจมตี การพึ่งพา input validation เพียวอย่างเดียวมักไม่เพียงพอ นั่นคือเหตุผลที่ Content Security Policy (CSP) เข้ามามีบทบาทสำคัญในฐานะเลเยอร์ป้องกันเชิงลึก (defense-in-depth) ที่บอกเบราว์เซอร์โดยตรงว่า "แหล่งที่มา" (source) ใดบ้างที่อนุญาตให้โหลดและรันได้
CSP ทำงานผ่าน HTTP response header ตัวหนึ่งชื่อ Content-Security-Policy ซึ่งประกอบด้วย directive ย่อยๆ หลายตัว เช่น default-src เป็นค่า fallback, script-src ควบคุมการรัน JavaScript, หรือ img-src จำกัดแหล่งที่มาของรูปภาพ ปัญหาคือการเขียน policy ที่ถูกต้องด้วยมือนั้นง่ายต่อการพลาด โดยเฉพาะเมื่อต้องจัดการหลาย directive พร้อม allowed sources ที่ซับซ้อน นี่คือจุดที่เครื่องมือ Content Security Policy Generator ของเราเข้ามาช่วย ให้คุณสร้าง CSP header ที่แข็งแรงและถูกต้องได้ผ่านหน้าจอแบบ interactive โดยไม่ต้องเขียน syntax เองเลย
บทความนี้จะพาคุณทั้งเข้าใจแนวคิดของ CSP ทั้งใช้งานเครื่องมือให้เกิดประโยชน์สูงสุด พร้อมตัวอย่าง policy สำหรับหลายสถานการณ์จริง เช่น SaaS dashboard, e-commerce checkout, หรือ static site ที่ใช้ CDN
ทำไมต้องใช้ CSP Generator?
การเขียน CSP ด้วยตนเองอาจดูตรงไปตรงมา แต่ในโปรเจกต์จริงที่มี third-party scripts, web fonts, analytics, และ API หลายตัว policy มักจะซับซ้อนและเปราะบาง เครื่องมือนี้ช่วยแก้ปัญหาเหล่านี้:
- สร้าง directive แบบ visual — คุณไม่ต้องจำ syntax หรือลืม directive ที่สำคัญ เพียงเปิด/ปิดและเพิ่ม source ผ่าน UI ที่อ่านง่าย
- ลดความเสี่ยงจาก human error — semicolon ตกหล่น, source ที่ผิดพลาด หรือ keyword ที่สะกดผิด ล้วนทำให้ policy พังโดยที่หน้าเว็บดูปกติจนกว่าจะเกิดเหตุ เครื่องมือสร้างผลลัพธ์ที่ถูกต้องทุกครั้ง
- มี preset สำหรับสถานการณ์รู้จัก — ไม่ว่าจะเป็น development, production แบบ strict หรือการใช้ CDN คุณเริ่มจากจุดที่เหมาะสมแทนที่จะเริ่มจากศูนย์
- Live validation ตรงหน้า — เครื่องมือตรวจหา unsafe-inline ใน script-src และเตือนทันที พร้อมตรวจความถูกต้องของ source value ผ่าน regex ก่อนคุณจะนำไป deploy
- เข้าใจผลกระทบทันที — เมื่อเปลี่ยนแปลง directive ผลลัพธ์ header ด้านล่างอัปเดตแบบ real-time ทำให้เห็นผลของการตั้งค่าแต่ละตัวทันที
- ประหยัดเวลาตอน hand-off — ส่ง policy ให้ทีม ops หรือ DevOps ได้เลย พร้อม copy/paste ที่สะอาดไม่มี typo
คุณสมบัติเด่น
| คุณสมบัติ | หน้าที่ |
|---|---|
| Interactive directives | จัดการ default-src, script-src, style-src, img-src, font-src, connect-src, frame-src, object-src รวมถึง base-uri และ form-action ผ่านหน้าจอเดียว |
| 3 presets พร้อมใช้ | เลือก DEVELOPMENT, PRODUCTION_STRICT หรือ CDN_ENABLED เพื่อเริ่มต้นอย่างรวดเร็ว |
| Live validation | เตือนเมื่อพบ unsafe-inline ใน script-src และตรวจ source value ผ่าน regex ทันที |
| CSP keywords ครบ | รองรับ 'self', 'none', 'unsafe-inline', 'unsafe-eval', nonce และ hash (sha256/384/512) รวมถึง data: และ https: |
| Copy/paste output | คัดลอก header ที่สร้างเสร็จไปใช้กับ Nginx, Apache หรือ meta tag ได้ทันที |
| ไม่ต้องสมัคร | ใช้งานได้ฟรีในเบราว์เซอร์ ไม่ต้อง login ไม่ต้องส่งข้อมูลออกไปที่ไหน |
เครื่องมือยังออกแบบให้ทำงานบนฝั่ง client ทั้งหมด นโยบายที่คุณสร้างไม่ถูกส่งไปยังเซิร์ฟเวอร์ใดๆ จึงปลอดภัยต่อข้อมูลภายในองค์กรด้วย นอกจากนี้ผลลัพธ์ยังอยู่ในรูปแบบที่นำไปวางใน Content-Security-Policy header หรือ <meta http-equiv> ได้ทั้งคู่ ทำให้เข้ากับทุก stack
วิธีใช้งาน CSP Generator
- เลือก preset หรือเริ่มจาก blank — เปิดหน้า CSP Generator แล้วเลือก preset ที่ตรงกับสถานการณ์ เช่น PRODUCTION_STRICT สำหรับเว็บที่ต้องการล็อกแน่น หรือเลือกเริ่มจาก blank หากต้องการควบคุมทุก directive เอง
- เพิ่ม allowed sources ให้แต่ละ directive — สำหรับทุก directive ที่ใช้งาน ให้เพิ่ม source ที่อนุญาต เช่น 'self' สำหรับ origin เดียวกัน, https://cdn.jsdelivr.net สำหรับ CDN หรือ 'nonce-...' สำหรับ inline script ที่มี nonce
- ตรวจสอบ validation warnings — สังเกตไอคอนเตือนถ้ามี unsafe-inline ใน script-src และไล่ดูว่ายังมี source ใดที่ระบุผิดรูปแบบบ้าง แก้ให้เรียบร้อยก่อนนำไปใช้
- Copy header ที่ได้ — เมื่อนโยบายพร้อม ให้คัดลอกบรรทัด Content-Security-Policy: ... ไปยังคลิปบอร์ด
- Deploy ไปยัง web server หรือ meta tag — วางใน config ของ Nginx/Apache, framework middleware (เช่น Next.js headers(), Express helmet) หรือฝังเป็น <meta http-equiv="Content-Security-Policy"> ใน <head> สำหรับเว็บที่แก้ header ไม่ได้
ทำความเข้าใจ CSP Directives
directive แต่ละตัวใน CSP ควบคุมประเภท resource ที่ต่างกัน การทำความเข้าใจหน้าที่ของแต่ละตัวจะช่วยให้คุณตั้งค่าได้ตรงกับความต้องการจริง:
- default-src — เป็น fallback ที่ใช้เมื่อ directive เฉพาะประเภทไม่ได้กำหนด ค่าที่ดีคือ 'self' หรือ 'none' แล้วค่อย "เปิด" directive อื่นที่จำเป็น
- script-src — directive สำคัญที่สุดในการต้าน XSS เพราะควบคุมว่าจะรัน JavaScript จาก source ใดได้บ้าง พยายามหลีกเลี่ยง 'unsafe-inline' และ 'unsafe-eval'
- style-src — ควบคุม stylesheet และ inline style ถ้าเว็บใช้ CSS framework ที่ inject style อาจต้องอนุญาตเฉพาะ hash หรือ nonce
- img-src — กำหนดว่ารูปภาพโหลดได้จากที่ใด มักต้องเปิด data: สำหรับ inline SVG/PNG และ https: สำหรับรูปจาก CDN
- connect-src — จำกัดการ fetch, XHR, WebSocket และ EventSource สำคัญมากสำหรับ SPA ที่เรียก API
- object-src / frame-src — object-src 'none' เป็นค่าที่แนะนำเพื่อบล็อก Flash/PDF plugin ที่ล้าสมัยและเป็นช่องโหว่ ส่วน frame-src 'none' บล็อกการฝัง iframe จากภายนอก
- base-uri — ป้องกันการฉีด <base> tag เพื่อหลอกให้ relative URL ชี้ไปโดเมนผู้โจมตี
- form-action — จำกัดปลายทางที่ฟอร์มจะส่งข้อมูลไปได้ ป้องกันการ exfiltrate ผ่านการส่งฟอร์ม
นอกจาก directive แล้วยังมี keywords ที่ใช้บ่อย:
- 'self' — อนุญาตเฉพาะ origin เดียวกัน (รวม scheme, host, port)
- 'none' — บล็อกทุกอย่างใน directive นั้น
- 'unsafe-inline' — อนุญาต inline element (เช่น <script> ฝังใน HTML) — หลีกเลี่ยงใน production
- 'unsafe-eval' — อนุญาต eval(), new Function() — เสี่ยง ใช้เฉพาะตอน dev
- 'nonce-<base64>' — อนุญาตเฉพาะ element ที่มี nonce ตรงกับ header (แนะนำสำหรับ inline script)
- '<hash-algorithm>-<base64>' — อนุญาตเฉพาะ inline content ที่ hash ตรง เช่น 'sha256-abc123...'
ตัวอย่าง policy ขนาดเล็กสำหรับเว็บ production ทั่วไป:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-a1b2c3d4e5f6'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'self'; form-action 'self';
policy นี้ล็อกทุกอย่างไว้ที่ 'self', อนุญาต inline script เฉพาะตัวที่มี nonce, อนุญาตรูปภาพจาก data: และทุก HTTPS origin, ใช้ web fonts จาก gstatic, เรียก API เฉพาะ domain ของตัวเอง และบล็อก plugin กับการ redirect ฟอร์ม
กรณีใช้งานจริง
SaaS Dashboard
แดชบอร์ด SaaS มักมี charts, การยืนยันตัวตน, การเรียก API หลายตัว และบางครั้งมี inline script เล็กน้อย policy ที่เหมาะคือเปิด 'self' สำหรับทุก directive เป็นหลัก แล้วขยายเฉพาะที่จำเป็น:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-XYZ123'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.myapp.com wss://realtime.myapp.com; font-src 'self' https://fonts.gstatic.com; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self';
ข้อสำคัญคือใช้ nonce สำหรับ inline script แทน unsafe-inline และเปิด WebSocket endpoint ที่ connect-src เท่านั้น
E-commerce Checkout
หน้า checkout ต้องโหลด payment widget จาก third party (เช่น Stripe, PayPal) จึงต้องเปิด frame-src และ script-src ให้กับโดเมนเหล่านั้น แต่ยังคงล็อก directive อื่นไว้แน่น:
Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com https://www.paypal.com; img-src 'self' data: https:; connect-src 'self' https://api.stripe.com; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self'; form-action 'self' https://checkout.stripe.com;
สังเกตว่า form-action ต้องอนุญาตโดเมนที่ฟอร์มส่งไปด้วย ไม่งั้นการ submit จะถูกบล็อก
Static Marketing Site + CDN
เว็บ static ที่ใช้ CDN สำหรับ CSS/JS framework เช่น Tailwind หรือ Bootstrap สามารถเริ่มจาก preset CDN_ENABLED ของเครื่องมือได้เลย policy จะอนุญาต cdn.jsdelivr.net, fonts.googleapis.com, fonts.gstatic.com และ API ตัวอย่างโดยอัตโนมัติ:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'self'; form-action 'self';
Single-Page App ที่มี API
SPA (React/Vue/Angular) ส่วนใหญ่ต้องเรียก API backend ที่แยก domain ดังนั้น connect-src จึงเป็น directive ที่ต้องดูแลเป็นพิเศษ แนะนำให้ระบุ origin ของ API อย่างชัดเจน ไม่ใช่เปิด https: กว้างๆ:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://cdn.example.com; connect-src 'self' https://api.example.com https://auth.example.com; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self';
เพราะ SPA มัก compile โค้ดเป็น bundle ที่มาจาก origin เดียวกัน จึงใช้ 'self' ที่ script-src ได้โดยไม่ต้องการ unsafe-inline
Best Practices
- เริ่มจาก report-only mode — ก่อน enforce จริง ให้ใช้ header Content-Security-Policy-Report-Only และส่ง violation ไปยัง endpoint ของตัวเอง เพื่อดูว่ามี request ใดถูกบล็อกก่อนจะส่งผลกระทบต่อผู้ใช้
- ค่อยๆ ขัดเกลา directive — เริ่มจาก default-src 'self' แล้วค่อยเปิด directive เฉพาะตามความจำเป็น ทีละตัว อย่าเปิดทุกอย่างพร้อมกันแล้วจะหาสาเหตุยากเวลาหน้าเว็บพัง
- หลีกเลี่ยง unsafe-inline ใน script-src เมื่อเป็น production — ใช้ nonce หรือ hash แทน ซึ่งเครื่องมือจะเตือนให้รู้ตัวอยู่แล้ว
- ใช้ nonce หรือ hash สำหรับ inline content — nonce เหมาะกับ inline content ที่เปลี่ยนทุก request (เช่น SSR), hash เหมาะกับ inline content คงที่ (เช่น critical CSS)
- ตั้ง object-src 'none' เสมอ — plugin เก่าๆ เช่น Flash แทบไม่มีเหตุผลให้ใช้แล้ว การบล็อกไว้จะตัดช่องโหว่ได้มากโดยไม่กระทบฟังก์ชันการใช้งาน
- ทดสอบหลังเปลี่ยนทุกครั้ง — เปิด DevTools ของเบราว์เซอร์ ดู tab Console และ Network ว่ามี resource ใดถูกบล็อกหรือเตือน CSP violation หรือไม่ โดยเฉพาะบนอุปกรณ์จริง
พร้อมสร้าง policy ที่ป้องกัน XSS และการ exfiltration แล้วหรือยัง? เปิดใช้งาน Content Security Policy Generator ฟรีได้ทันที ไม่ต้องสมัคร ไม่ต้องติดตั้ง คัดลอกผลลัพธ์ไป deploy กับเว็บของคุณได้เลยวันนี้
เครื่องมือที่เกี่ยวข้อง
หากคุณกำลังเสริมความปลอดภัยให้เว็บแอปพลิเคชัน เครื่องมือเหล่านี้ก็ทำงานคู่กับ CSP ได้ดีเช่นกัน:
- SRI Hash Generator — ตรวจ integrity ของ third-party scripts
- htaccess Generator — ตั้ง security headers ผ่าน Apache
- CORS Header Generator — ควบคุม cross-origin access
โชคดีกับการรักษาความปลอดภัย!