SCT

กำลังเตรียมประสบการณ์ดิจิทัล

ยกระดับความปลอดภัยเว็บด้วย HTTP Security Headers ตามคู่มือ MDN

การป้องกันเว็บหลายอย่างทำได้ด้วยการตั้งค่า HTTP Header ไม่กี่บรรทัด แต่เว็บไทยจำนวนมากยังไม่ได้ตั้ง บทความนี้อิงคู่มือความปลอดภัยของ MDN Web Docs อธิบาย CSP, HSTS, และเฮดเดอร์สำคัญอื่น ๆ พร้อมค่าที่แนะนำสำหรับนำไปใช้ได้ทันที

การป้องกันเว็บหลายอย่างทำได้ด้วยการตั้งค่า HTTP Header ไม่กี่บรรทัด แต่เว็บไทยจำนวนมากยังไม่ได้ตั้ง บทความนี้อิงคู่มือความปลอดภัยของ MDN Web Docs อธิบาย CSP, HSTS, และเฮดเดอร์สำคัญอื่น ๆ พร้อมค่าที่แนะนำสำหรับนำไปใช้ได้ทันที

แนวป้องกันที่ถูกที่สุดของเว็บคุณ

HTTP Security Headers คือคำสั่งที่เซิร์ฟเวอร์ส่งไปบอกเบราว์เซอร์ว่าให้บังคับใช้กติกาความปลอดภัยอะไรบ้างกับหน้าเว็บของเรา จุดเด่นคือ ต้นทุนต่ำมาก เพราะเป็นเพียงการตั้งค่าไม่กี่บรรทัดที่ Web Server, Reverse Proxy หรือ CDN แต่ช่วยตัดการโจมตีทั้งกลุ่ม เช่น Clickjacking และลดความรุนแรงของ XSS ได้จริง

MDN Web Docs ของ Mozilla ซึ่งเป็นเอกสารอ้างอิงมาตรฐานเว็บที่นักพัฒนาทั่วโลกใช้ มีชุดคู่มือ Practical Security Implementation Guides ที่อธิบายเฮดเดอร์แต่ละตัวพร้อมค่าแนะนำ บทความนี้คัดตัวที่สำคัญที่สุดมาเรียงตามลำดับที่ควรลงมือ

HSTS: บังคับ HTTPS ทุกครั้ง ไม่มีข้อยกเว้น

แม้เว็บจะมี HTTPS แล้ว แต่ถ้าผู้ใช้พิมพ์ URL โดยไม่ใส่ https:// คำขอแรกอาจวิ่งผ่าน HTTP ซึ่งถูกดักและปลอมได้ (SSL Stripping) เฮดเดอร์ Strict-Transport-Security แก้ปัญหานี้โดยสั่งให้เบราว์เซอร์จำไว้ว่าโดเมนนี้ต้องเชื่อมต่อผ่าน HTTPS เท่านั้นตามระยะเวลาที่กำหนด

ค่าที่แนะนำโดยทั่วไปคือ max-age=31536000 (1 ปี) พร้อม includeSubDomains เมื่อมั่นใจว่าทุกซับโดเมนรองรับ HTTPS แล้ว ข้อควรระวังคือทดสอบด้วย max-age สั้น ๆ ก่อน เพราะเมื่อเบราว์เซอร์จำค่าแล้ว หากซับโดเมนไหนยังไม่มี HTTPS ผู้ใช้จะเข้าไม่ได้จนกว่าค่าจะหมดอายุ

ภาพประกอบเนื้อหาหมวดเว็บ
ภาพประกอบเนื้อหาหมวดเว็บ

Content Security Policy: เกราะชั้นสองของ XSS

CSP คือเฮดเดอร์ที่ทรงพลังที่สุดในกลุ่มนี้ ทำหน้าที่ประกาศว่าหน้าเว็บอนุญาตให้โหลดสคริปต์ รูปภาพ สไตล์ จากแหล่งใดบ้าง หากผู้โจมตีฉีดสคริปต์แปลกปลอมเข้ามาได้ เบราว์เซอร์จะปฏิเสธการรันเพราะไม่อยู่ในรายการอนุญาต CSP จึงเป็นแนวป้องกันชั้นสอง (Defense in Depth) ที่ช่วยแม้โค้ดเราจะมีช่องโหว่ XSS หลุดไป

การเริ่มใช้กับเว็บที่มีอยู่แล้วควรเริ่มจากโหมด Content-Security-Policy-Report-Only ซึ่งยังไม่บล็อกจริงแต่รายงานสิ่งที่จะถูกบล็อกมาให้ดูก่อน เก็บรายงานสัก 1-2 สัปดาห์ ปรับนโยบายจนไม่กระทบการทำงานปกติ แล้วจึงเปิดบังคับจริง แนวทางสมัยใหม่ที่ MDN แนะนำคือใช้ nonce หรือ hash กับสคริปต์ แทน Whitelist โดเมนยาว ๆ ที่ดูแลยาก

ชุดเฮดเดอร์พื้นฐานที่ควรมีทุกเว็บ

X-Frame-Options: DENY (หรือ CSP frame-ancestors) ป้องกันเว็บถูกฝังใน iframe ของผู้อื่นเพื่อหลอกให้คลิก (Clickjacking), X-Content-Type-Options: nosniff ป้องกันเบราว์เซอร์เดาประเภทไฟล์ผิดจนรันสคริปต์ที่ไม่ตั้งใจ และ Referrer-Policy: strict-origin-when-cross-origin ป้องกัน URL ภายใน (ที่อาจมีข้อมูลอ่อนไหว) รั่วไปกับการคลิกลิงก์ออกนอกเว็บ

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

ภาพประกอบเสริมของบทความนี้
ภาพประกอบเสริมของบทความนี้

คุกกี้ปลอดภัย: สามแฟล็กที่ห้ามลืม

คุกกี้เซสชันคือกุญแจบัญชีผู้ใช้ จึงต้องตั้งแฟล็กครบสามตัว ได้แก่ Secure (ส่งผ่าน HTTPS เท่านั้น), HttpOnly (JavaScript อ่านไม่ได้ ทำให้ขโมยผ่าน XSS ยากขึ้นมาก) และ SameSite ซึ่งควบคุมการแนบคุกกี้ไปกับคำขอข้ามไซต์ โดยค่า Lax เป็นสมดุลที่ดีสำหรับเว็บทั่วไป และ Strict สำหรับหน้าที่อ่อนไหวเช่นระบบการเงิน

SameSite ยังเป็นแนวป้องกันสำคัญของการโจมตี CSRF (Cross-Site Request Forgery) ที่หลอกให้เบราว์เซอร์ของเหยื่อส่งคำขอโดยไม่รู้ตัว ทั้งนี้ MDN แนะนำให้ใช้ควบคู่กับ CSRF Token ในฟอร์มสำคัญ ไม่พึ่ง SameSite เพียงอย่างเดียว

ตรวจสอบและรักษาระดับอย่างต่อเนื่อง

หลังตั้งค่าแล้ว ใช้เครื่องมือฟรีอย่าง Mozilla HTTP Observatory สแกนเว็บเพื่อรับคะแนนและคำแนะนำรายข้อ หรือดูเฮดเดอร์จริงได้เองผ่าน DevTools แท็บ Network เป้าหมายที่เหมาะสมสำหรับเว็บธุรกิจคือเกรด B ขึ้นไป โดยไล่แก้จากข้อที่กระทบน้อยแต่ได้คะแนนมากก่อน เช่น nosniff และ Referrer-Policy

สุดท้าย ให้เพิ่มการตรวจเฮดเดอร์เข้าไปใน CI/CD หรือระบบ Monitoring เพื่อกันการตั้งค่าหายเงียบ ๆ ตอนย้ายเซิร์ฟเวอร์หรือเปลี่ยน CDN ซึ่งเกิดขึ้นบ่อยกว่าที่คิด ความปลอดภัยของเว็บไม่ใช่โครงการที่จบครั้งเดียว แต่คือมาตรฐานที่ต้องรักษาไว้ทุกการเปลี่ยนแปลง

สิ่งที่ควรจำ

  • แนวป้องกันที่ถูกที่สุดของเว็บคุณ
  • HSTS: บังคับ HTTPS ทุกครั้ง ไม่มีข้อยกเว้น
  • Content Security Policy: เกราะชั้นสองของ XSS
แหล่งอ้างอิงเรียบเรียงจาก MDN Web Docs — Website Security Practical Guides — อ่านเอกสารต้นฉบับ
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่ info@smart-cyber-tech.com

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

เรียนรู้ต่อเนื่อง

เร่งความเร็วเว็บด้วย Core Web Vitals: คู่มือเริ่มต้นสำหรับทีมพัฒนา เว็บ

เร่งความเร็วเว็บด้วย Core Web Vitals: คู่มือเริ่มต้นสำหรับทีมพัฒนา

เว็บที่โหลดช้าเพียง 1 วินาทีอาจทำให้ Conversion ลดลงอย่างมีนัยสำคัญ บทความนี้สรุปแนวทางจากคอร์ส Learn Performance ของ Google web.dev อธิบายตัวชี้วัด Core Web Vitals ทั้ง LCP, INP และ CLS พร้อมเทคนิคปรับปรุงที่ทีมพัฒนาไทยนำไปใช้ได้ทันที

อ่านบทความ
OWASP Top 10 ฉบับปี 2025: ความเสี่ยงเว็บแอปที่นักพัฒนาทุกคนต้องรู้ ความปลอดภัย

OWASP Top 10 ฉบับปี 2025: ความเสี่ยงเว็บแอปที่นักพัฒนาทุกคนต้องรู้

OWASP ออก Top 10 ฉบับปี 2025 หลังจากฉบับก่อนหน้าถึง 4 ปี โดยมีการเปลี่ยนแปลงสำคัญคือความเสี่ยงด้าน Supply Chain ขึ้นมาเป็นอันดับ 3 บทความนี้สรุปสาระสำคัญของแต่ละหมวด พร้อมแนวทางป้องกันที่ทีมพัฒนานำไปปรับใช้ได้จริง

อ่านบทความ
ลดค่าใช้จ่ายคลาวด์อย่างเป็นระบบตามแนวทาง AWS Well-Architected คลาวด์

ลดค่าใช้จ่ายคลาวด์อย่างเป็นระบบตามแนวทาง AWS Well-Architected

องค์กรจำนวนมากจ่ายค่าคลาวด์เกินจำเป็น 20-30% จากทรัพยากรที่ไม่ได้ใช้และขนาดที่ใหญ่เกินงาน บทความนี้สรุปหลักการจาก Cost Optimization Pillar ของ AWS Well-Architected Framework ตั้งแต่การมองเห็นค่าใช้จ่าย การเลือกโมเดลราคา ไปจนถึงการสร้างวัฒนธรรม FinOps ในทีม

อ่านบทความ

อยากให้ทีมเราช่วยนำไปใช้จริง?

ตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย

ปรึกษาทีมของเรา