Network & Security

Content Security Policy (CSP) คืออะไร? คู่มือ Web Security ป้องกัน XSS 2026 สำหรับ SME ไทย

Content Security Policy (CSP) คือหนึ่งใน HTTP Header ที่ช่วยป้องกัน XSS, Clickjacking และ Data Injection สำหรับเว็บไซต์ธุรกิจในปี 2026 คู่มือตั้งค่า CSP ให้ถูกต้องบน Nginx, Laravel, Next.js

AF
ADS FIT Team
·8 นาที
Share:
Content Security Policy (CSP) คืออะไร? คู่มือ Web Security ป้องกัน XSS 2026 สำหรับ SME ไทย

# Content Security Policy (CSP) คืออะไร? คู่มือ Web Security ป้องกัน XSS 2026 สำหรับ SME ไทย

การโจมตีเว็บไซต์ด้วย Cross-Site Scripting (XSS) ยังคงเป็น 1 ใน OWASP Top 10 มานานหลายปี และในปี 2026 ที่ AI สามารถสร้างสคริปต์โจมตีอัตโนมัติได้ภายในไม่กี่วินาที การป้องกันแบบดั้งเดิมเพียงอย่างเดียวจึงไม่เพียงพออีกต่อไป

Content Security Policy (CSP) คือ HTTP Response Header ที่บอกเบราว์เซอร์ว่าแหล่ง (origin) ใดอนุญาตให้โหลดสคริปต์ สไตล์ รูปภาพ ฟอนต์ และทรัพยากรอื่น ๆ ได้บ้าง เปรียบเหมือน Firewall ฝั่ง Browser ที่ช่วยตัดโอกาสการรันโค้ดที่ไม่ได้รับอนุญาต

ในคู่มือฉบับภาษาไทยนี้ PM, DevOps และนักพัฒนา Laravel / Next.js จะได้เรียนรู้ตั้งแต่หลักการของ CSP การเขียน policy ขั้นต้นถึงขั้นสูง การใช้ nonce / hash การตั้งค่าบน Nginx, Laravel และ Next.js พร้อม Checklist สำหรับตรวจ Production

CSP ทำงานอย่างไร?

เมื่อผู้ใช้เปิดเว็บไซต์ เซิร์ฟเวอร์จะส่ง HTTP Header ชื่อ `Content-Security-Policy` กลับมาพร้อมกฎ เช่น

```

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data:;

```

เบราว์เซอร์จะ

  • บังคับให้ทรัพยากรทั้งหมดโหลดจาก origin ที่อนุญาตเท่านั้น
  • บล็อกการรัน inline script ที่ไม่มี nonce/hash
  • ปฏิเสธการทำ `eval()` และ Function() โดย default
  • รายงานการละเมิดไปยัง endpoint ที่เรากำหนด (report-to)
  • ถ้ามีคน inject `<script>stealCookie()</script>` เข้ามาในหน้าเว็บ เบราว์เซอร์จะไม่รันเลย เพราะ policy ไม่อนุญาต inline script

    ทำไม SME ไทยต้องใช้ CSP ในปี 2026?

  • **PDPA Compliance**: ลดความเสี่ยงข้อมูลลูกค้ารั่วไหลจาก XSS ซึ่งอาจโดนปรับตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล
  • **Trust Signals จาก Google**: Core Web Vitals รายงาน security-related warning ที่ส่งผลต่อ SEO
  • **ป้องกัน Supply Chain Attack**: ถ้า CDN หรือ 3rd-party script ถูก hack CSP จะตัดการรันทันที
  • **Reduce Breach Impact**: แม้จะมี bug XSS ในโค้ด ก็จะไม่สามารถโจมตีสำเร็จถ้า CSP ตั้งไว้ถูก
  • CSP Directives ที่ต้องรู้

    | Directive | หน้าที่ |

    |---|---|

    | `default-src` | ค่า default สำหรับทรัพยากรทุกประเภท |

    | `script-src` | ควบคุมการโหลดและรัน JavaScript |

    | `style-src` | ควบคุม CSS |

    | `img-src` | ควบคุมแหล่งของรูปภาพ |

    | `connect-src` | ควบคุม fetch / XHR / WebSocket |

    | `font-src` | ควบคุมฟอนต์ (Google Fonts, etc.) |

    | `frame-ancestors` | ป้องกัน Clickjacking (แทน X-Frame-Options) |

    | `form-action` | ควบคุมว่าฟอร์มจะ submit ไปที่ไหนได้ |

    | `upgrade-insecure-requests` | บังคับ HTTPS |

    | `report-to` | ส่ง violation report ไปยัง endpoint |

    วิธีเริ่มใช้ CSP แบบปลอดภัย (Step-by-Step)

    การเปิด CSP แบบ strict ในครั้งเดียวอาจทำให้เว็บพัง แนะนำทำทีละขั้น

    Step 1: เริ่มด้วย Report-Only

    ใช้ header `Content-Security-Policy-Report-Only` เพื่อดู violation โดยไม่ block การทำงาน

    ```

    Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;

    ```

    Step 2: รวบรวม Violation Report 7-14 วัน

    ตั้ง endpoint รับ JSON violation report ตรวจดูว่ามี 3rd-party ตัวไหนที่ต้องเพิ่มใน whitelist บ้าง

    Step 3: Refine Policy และเปิด Enforcement

    เมื่อมั่นใจแล้ว เปลี่ยน header เป็น `Content-Security-Policy` (enforce) และใช้ nonce แทน `unsafe-inline`

    ```

    Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m123' https://cdn.jsdelivr.net; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

    ```

    Step 4: Monitor ต่อเนื่อง

    ใช้เครื่องมือเช่น Report URI, Sentry หรือ self-host endpoint เก็บ violation log ทุกวัน

    ตัวอย่างการตั้งค่า CSP บน Production Stack

    Nginx

    ```nginx

    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-$request_id' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; upgrade-insecure-requests;" always;

    ```

    Laravel (middleware)

    ```php

    public function handle($request, Closure $next)

    {

    $response = $next($request);

    $nonce = base64_encode(random_bytes(16));

    $response->headers->set(

    'Content-Security-Policy',

    "default-src 'self'; script-src 'self' 'nonce-{$nonce}'; object-src 'none';"

    );

    view()->share('cspNonce', $nonce);

    return $response;

    }

    ```

    Next.js (next.config.js)

    ```javascript

    const csp = `default-src 'self'; script-src 'self' 'nonce-NEXT_NONCE'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none';`;

    module.exports = {

    async headers() {

    return [{

    source: '/(.*)',

    headers: [{ key: 'Content-Security-Policy', value: csp }]

    }];

    }

    };

    ```

    เปรียบเทียบ CSP vs WAF vs Input Validation

    | มาตรการ | จุดเด่น | จุดด้อย |

    |---|---|---|

    | Input Validation | ป้องกันที่ต้นทาง | พลาดง่ายถ้ามี bug |

    | WAF | บล็อก pattern การโจมตี | bypass ได้ด้วย payload ใหม่ |

    | Content Security Policy | ป้องกันที่ browser ปลายทาง | ตั้งค่าซับซ้อน ต้อง maintain |

    การใช้ทั้ง 3 ชั้นพร้อมกัน (Defense in Depth) คือแนวทางมาตรฐานในปี 2026

    ข้อผิดพลาดที่พบบ่อยและวิธีแก้

  • **ใช้ `unsafe-inline` และ `unsafe-eval`**: ลด security เหลือศูนย์ ควรเปลี่ยนเป็น nonce/hash
  • **ตั้ง wildcard กว้างเกิน** เช่น `*` หรือ `https:` ควรระบุโดเมนชัดเจน
  • **ไม่มี `frame-ancestors`**: เสี่ยง Clickjacking ควรตั้งเป็น `'none'` หรือ `'self'`
  • **ลืม report endpoint**: ทำให้ตรวจ attack ไม่ได้
  • **ทดสอบแต่ Dev**: Production มี 3rd-party script มากกว่า ต้องทดสอบจริง
  • Checklist สำหรับ Production

  • ใช้ Report-Only ก่อน Enforce อย่างน้อย 2 สัปดาห์
  • กำหนด `default-src 'self'` เป็นจุดเริ่มต้น
  • ใช้ nonce หรือ hash แทน unsafe-inline
  • ตั้ง `object-src 'none'` และ `base-uri 'self'`
  • ตั้ง `frame-ancestors 'none'` ถ้าไม่ให้ฝังในเว็บอื่น
  • เปิด `upgrade-insecure-requests`
  • ตั้ง report-to endpoint และ monitor violation
  • ทดสอบด้วย Mozilla Observatory หรือ securityheaders.com
  • สรุปและขั้นตอนต่อไป

    Content Security Policy คือการลงทุนด้านความปลอดภัยที่ต้นทุนต่ำแต่ได้ผลสูง เหมาะกับ SME ไทยที่ทำ e-commerce, แอปธนาคาร, ระบบจัดการภายใน (ERP/CRM) และเว็บไซต์ที่เก็บข้อมูลลูกค้า

    ถ้าคุณกำลังตั้ง CSP ครั้งแรกและไม่แน่ใจว่าจะ break อะไรบ้าง ทีม ADS FIT ช่วยออกแบบ policy, monitor violation report และ harden infrastructure ทั้ง Nginx, Laravel, Next.js ให้ปลอดภัยตามมาตรฐาน OWASP ASVS 4.0

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

  • OWASP Top 10 LLM 2026
  • HTTPS & HSTS Configuration Guide
  • Web Application Firewall (WAF) สำหรับ SME
  • พร้อมเสริมเกราะป้องกัน XSS และ Clickjacking ให้เว็บของคุณแล้วหรือยัง? ติดต่อ ADS FIT เพื่อตรวจสุขภาพความปลอดภัยของระบบฟรี

    Tags

    #CSP#Content Security Policy#XSS#Web Security#Headers#SME#2026

    สนใจโซลูชันนี้?

    ปรึกษาทีม ADS FIT ฟรี เราพร้อมออกแบบระบบที่ฟิตกับธุรกิจของคุณ

    ติดต่อเรา →

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