ตั้งค่า Security Headers ใน .htaccess ป้องกัน XSS CSRF Clickjacking

เว็บส่วนใหญ่ถูกโจมตีผ่านช่องโหว่พื้นฐานที่ป้องกันได้ด้วยการเพิ่มไม่กี่บรรทัดใน .htaccess นั่นคือ HTTP Security Headers — คำสั่งที่เซิร์ฟเวอร์ส่งให้เบราว์เซอร์เพื่อบังคับใช้กฎความปลอดภัย เช่น บังคับ HTTPS เสมอ ห้ามฝังเว็บใน iframe ของผู้อื่น และจำกัดแหล่งสคริปต์ บทความนี้อธิบาย Header สำคัญและวิธีเพิ่มบน DirectAdmin

Security Headers คืออะไร

เมื่อเบราว์เซอร์ขอหน้าเว็บ เซิร์ฟเวอร์จะส่ง HTTP Response Headers กลับมาพร้อมเนื้อหา Security Headers คือ Header กลุ่มหนึ่งที่สั่งเบราว์เซอร์ว่าให้บังคับใช้กฎความปลอดภัยอย่างไร เช่น ให้ใช้ HTTPS เท่านั้น ห้ามแสดงหน้าใน iframe หรืออนุญาตให้โหลดสคริปต์จากแหล่งใดบ้าง เบราว์เซอร์สมัยใหม่ทุกตัวเข้าใจ Header เหล่านี้และบังคับใช้ให้อัตโนมัติ

Header สำคัญที่ควรมี

Header	ป้องกัน	ค่าที่แนะนำ
Strict-Transport-Security (HSTS)	บังคับ HTTPS กันการดักข้อมูล	max-age=31536000; includeSubDomains
X-Frame-Options	Clickjacking (ฝังใน iframe)	SAMEORIGIN
X-Content-Type-Options	MIME sniffing	nosniff
Referrer-Policy	ข้อมูล Referrer รั่ว	strict-origin-when-cross-origin
Content-Security-Policy (CSP)	XSS, การฝังสคริปต์อันตราย	กำหนดแหล่งที่อนุญาต (ดูด้านล่าง)

เพิ่ม Security Headers ใน .htaccess

บน Hosting ที่ใช้ Apache/LiteSpeed (รวม DirectAdmin) เพิ่มชุดคำสั่งนี้ในไฟล์ .htaccess ที่โฟลเดอร์ public_html ของเว็บ:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

บันทึกแล้วเซิร์ฟเวอร์จะใช้ค่าทันทีโดยไม่ต้อง Restart เพราะ .htaccess อ่านทุก Request หากต้องการประกอบค่าแบบเลือกได้เองและคัดลอกไปใช้ ลองใช้ เครื่องมือ Security Headers Generator ของ AsiaGB ที่สร้างชุดคำสั่งสำหรับ .htaccess หรือ Nginx ให้อัตโนมัติ

Content-Security-Policy ใช้ให้ถูก

CSP คือ Header ที่ทรงพลังที่สุดในการลด XSS เพราะมันระบุว่าเบราว์เซอร์โหลดสคริปต์ สไตล์ และทรัพยากรได้จากแหล่งใดบ้าง สคริปต์ที่ถูกแทรกจากภายนอกที่ไม่ได้อนุญาตจะถูกบล็อก ตัวอย่างนโยบายพื้นฐาน:

Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self'; object-src 'none'; frame-ancestors 'self'; base-uri 'self'"

เริ่มจากนโยบายพื้นฐานก่อนแล้วค่อยปรับ เพราะถ้าตั้งเข้มเกินไปทรัพยากรภายนอกที่เว็บใช้จริง เช่น Google Fonts หรือ Analytics อาจถูกบล็อกจนหน้าเพี้ยน วิธีปรับคือเปิด Console ของเบราว์เซอร์ ดูว่ามีอะไรถูกบล็อก แล้วค่อยอนุญาตเพิ่มทีละแหล่ง

ตรวจสอบว่า Header ทำงาน

หลังเพิ่ม Header ควรยืนยันว่ามันถูกส่งจริง ทำได้หลายวิธี:

• เปิด DevTools ของเบราว์เซอร์ (F12) ไปที่แท็บ Network คลิกที่ Request ของหน้า แล้วดูส่วน Response Headers
• ใช้เครื่องมือออนไลน์ตรวจ Security Header ของเว็บเพื่อดูคะแนนและรายการที่ยังขาด — เช่น เครื่องมือตรวจ Security Headers ของ dnsxray.com ที่ให้เกรดและบอกว่าควรเพิ่ม Header ใด
• สั่ง curl -I https://yourdomain.com เพื่อดู Header ทั้งหมดที่เซิร์ฟเวอร์ส่ง

ทำไมเว็บไทยทั่วไปก็ควรใส่ Security Headers

หลายคนคิดว่า Security Headers เป็นเรื่องของเว็บใหญ่หรือเว็บธนาคารเท่านั้น แต่ความจริงคือเว็บเล็กและเว็บองค์กรทั่วไป ตกเป็นเป้าหมายบ่อยกว่า เพราะมักไม่มีการป้องกันพื้นฐาน บอทอัตโนมัติจะไล่สแกนหาเว็บที่ไม่มี Header เหล่านี้เพื่อหาช่องโจมตี เช่น ฝังเว็บใน iframe เพื่อหลอกคลิก หรือแทรกสคริปต์ผ่านช่องโหว่ XSS การเพิ่ม Header ไม่กี่บรรทัดจึงเป็นการลดความเสี่ยงที่คุ้มค่าที่สุดเมื่อเทียบกับเวลาที่ใช้

นอกจากความปลอดภัยแล้ว Header บางตัวยังส่งผลทางอ้อมต่อความน่าเชื่อถือและ SEO เช่น การบังคับ HTTPS ด้วย HSTS ทำให้ผู้ใช้ไม่เจอหน้าเตือน "ไม่ปลอดภัย" และ Google ก็ใช้ HTTPS เป็นสัญญาณการจัดอันดับอยู่แล้ว เว็บที่ตั้งค่าความปลอดภัยครบจึงดูเป็นมืออาชีพและสร้างความมั่นใจให้ผู้เข้าชมมากกว่า

ลำดับการเพิ่ม Header สำหรับมือใหม่

ถ้าเพิ่งเริ่ม ไม่ต้องใส่ทุก Header พร้อมกัน แนะนำทำทีละขั้นเพื่อลดความเสี่ยงที่เว็บจะพัง:

1. เริ่มจาก X-Content-Type-Options และ X-Frame-Options ก่อน เพราะปลอดภัยที่สุด แทบไม่มีผลข้างเคียงกับเว็บทั่วไป
2. เพิ่ม Referrer-Policy และ Strict-Transport-Security เมื่อ SSL ของเว็บทำงานเรียบร้อยทุกหน้าแล้ว (ยังไม่ใส่ preload)
3. ค่อยเพิ่ม Content-Security-Policy เป็นขั้นสุดท้าย เพราะต้องปรับให้เข้ากับสคริปต์ภายนอกที่เว็บใช้จริง โดยเริ่มจากนโยบายหลวมแล้วค่อยรัดเข้า
4. ทุกครั้งที่เพิ่ม Header ใหม่ ให้ทดสอบเว็บทันทีและเปิด Console ดูว่ามีอะไรถูกบล็อกหรือไม่

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

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

• ใส่ Header ซ้ำ — ถ้าทั้ง .htaccess และแอป (เช่น WordPress plugin) ตั้ง Header เดียวกัน อาจซ้ำหรือขัดกัน ให้เลือกตั้งที่เดียว
• CSP เข้มจนเว็บพัง — เริ่มจากนโยบายหลวมแล้วค่อยรัดเข้า อย่าตั้ง script-src 'self' ทันทีถ้าเว็บใช้สคริปต์ภายนอกอยู่
• เปิด HSTS preload เร็วเกินไป — preload เหมาะกับเว็บที่ HTTPS พร้อมสมบูรณ์ทุก Subdomain แล้วเท่านั้น

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

Security Headers ใส่ที่ไหนบน DirectAdmin

ใส่ในไฟล์ .htaccess ที่โฟลเดอร์ public_html ของเว็บได้เลย DirectAdmin รองรับ .htaccess โดยตรง บันทึกแล้วมีผลทันทีโดยไม่ต้อง Restart เซิร์ฟเวอร์

CSP ทำให้เว็บพังได้ไหม

ได้ถ้าตั้งเข้มเกินไปจนบล็อกทรัพยากรภายนอกที่เว็บใช้จริง เช่น Google Fonts หรือ Analytics แนะนำเริ่มจากนโยบายพื้นฐาน เปิด Console ดูว่าอะไรถูกบล็อก แล้วค่อยอนุญาตเพิ่มทีละแหล่ง

HSTS preload ควรเปิดเลยไหม

ไม่ควรรีบ ควรเปิด preload เฉพาะเมื่อมั่นใจว่าทุก Subdomain รองรับ HTTPS ครบแล้ว เพราะเมื่อลงทะเบียนในรายการ preload ของเบราว์เซอร์แล้วการถอนออกทำได้ยากและใช้เวลานาน

จะตรวจว่า Header ทำงานจริงได้อย่างไร

ดูได้จาก DevTools แท็บ Network ส่วน Response Headers ใช้คำสั่ง curl -I หรือใช้เครื่องมือตรวจ Security Headers ออนไลน์ที่ให้เกรดและบอกรายการ Header ที่ยังขาด