HTTP Security Headers คู่มือรักษาความปลอดภัยเว็บไซต์สำหรับผู้ดูแลระบบ
HTTP security headers are powerful mechanisms that protect your website from attacks like XSS, CSRF, and clickjacking. Despite their importance, most websites don't implement them properly, leaving user data vulnerable. This guide explains each header in detail, how to configure them, and how to verify they're working correctly for your site.
HTTP security headers เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการป้องกันเว็บไซต์จากการโจมตีต่างๆ เช่น XSS (Cross-Site Scripting), CSRF, และ clickjacking ส่วนใหญ่ของเว็บไซต์ยังไม่ได้กำหนด headers เหล่านี้อย่างครบถ้วน ซึ่งเป็นช่องโหว่ที่สำคัญในการรักษาความปลอดภัยของข้อมูลผู้ใช้ บทความนี้จะอธิบายแต่ละ header อย่างละเอียด วิธีการตั้งค่า และวิธีทดสอบให้แน่ใจว่าทำงานถูกต้อง
สารบัญ
- HTTP Security Headers คืออะไร และทำไมเว็บไซต์ทุกแห่งต้องใช้
- Content-Security-Policy (CSP) - ควบคุมแหล่งเนื้อหาโดยละเอียด
- HSTS (Strict-Transport-Security) - บังคับใช้ HTTPS ตลอดเวลา
- X-Content-Type-Options และ X-Frame-Options - ป้องกัน MIME Sniffing และ Clickjacking
- Referrer-Policy และ Permissions-Policy - ควบคุมข้อมูลอ้างอิงและสิทธิ์อนุญาต
- วิธีเพิ่ม Security Headers - ตัวอย่าง Apache .htaccess และ Nginx
- ทดสอบ Headers ด้วยเครื่องมือสแกน Online
- ความผิดพลาดทั่วไป CSP ที่ทำให้เว็บไซต์พัง
- Security Headers เทียบกับ SSL Certificate - แต่ละตัวป้องกันอะไร
- FAQ
HTTP Security Headers คืออะไร และทำไมเว็บไซต์ทุกแห่งต้องใช้
HTTP security headers เป็นคำสั่งที่เซิร์ฟเวอร์ส่งไปในการตอบสนอง HTTP เพื่อบอกให้เบราว์เซอร์รู้ว่าต้องจัดการปัญหาด้านความปลอดภัยอย่างไร ตัวอย่างเช่น ป้องกันการโจมตี XSS, MIME sniffing, clickjacking และการรั่วไหลของข้อมูล referrer Headers เหล่านี้เป็นเครื่องป้องกันชั้นเพิ่มเติมแม้ว่าคุณได้ป้องกันปัญหาเหล่านี้ในโค้ดแล้ว มันให้ความมั่นใจเพิ่มเติมว่าผู้โจมตีจะไม่สามารถทำร้ายผู้ใช้งานของคุณได้ง่าย
- ป้องกัน XSS attacks โดยควบคุมแหล่งเนื้อหาที่อนุญาต
- บังคับใช้ HTTPS ผ่าน HSTS
- ป้องกัน clickjacking โดยจำกัดการ iframe
- ควบคุมการส่งข้อมูล referrer ไปยังเว็บไซต์อื่น
- ป้องกัน MIME sniffing ที่ไม่ถูกต้อง
- ป้องกัน plugin/microphone/camera access จากไซต์ที่ไม่ได้รับอนุญาต
Content-Security-Policy (CSP) - ควบคุมแหล่งเนื้อหาโดยละเอียด
Content-Security-Policy (CSP) เป็น header ที่ทรงพลังที่สุดสำหรับป้องกัน XSS attacks โดยช่วยให้คุณระบุว่าไซต์ใดสามารถโหลด scripts, stylesheets, images, fonts และทรัพยากรอื่นๆ ได้ CSP มีสองแบบ: directive ที่ป้องกัน (prevent) เหตุการณ์ที่อันตรายและ reporting mode ที่เพียงแจ้งเตือน คุณสามารถเริ่มด้วย report-only mode เพื่อทดสอบก่อนที่จะบังคับใช้
- default-src 'self' - อนุญาตแหล่งที่เป็นตัวเดียวกันเท่านั้น
- script-src - ควบคุมว่า JavaScript มาจากที่ใด
- style-src - ระบุแหล่งที่อนุญาตสำหรับ CSS
- img-src - กำหนดที่มาของรูปภาพ
- font-src - ควบคุมแหล่งฟอนต์
- frame-ancestors 'none' - ป้องกัน clickjacking
HSTS (Strict-Transport-Security) - บังคับใช้ HTTPS ตลอดเวลา
HSTS header บอกให้เบราว์เซอร์ว่าต้องเชื่อมต่อกับเว็บไซต์ของคุณผ่าน HTTPS เสมอ แม้ว่าผู้ใช้จะพิมพ์ URL หรือกดลิงก์ที่ใช้ HTTP ก็ตาม สิ่งนี้ป้องกัน man-in-the-middle attacks และการ downgrade จาก HTTPS เป็น HTTP header นี้รวมถึง max-age (ระยะเวลาที่เบราว์เซอร์จะจดจำนโยบายนี้ มีหน่วยเป็นวินาที) และตัวเลือก includeSubDomains ที่บังคับใช้นโยบายกับ subdomains ทั้งหมด
- ปกป้องจาก man-in-the-middle attacks ที่พยายามลดระดับ (downgrade) จาก HTTPS ลงมาเป็น HTTP
- บอกเบราว์เซอร์ว่าต้องจดจำนโยบายนี้ไว้เป็นเวลานาน หากตั้งค่าไว้
- เป็นตัวเลือก includeSubDomains เพื่อครอบคลุม subdomains
- ลดการเรียกทำซ้ำ 301 redirects จาก HTTP ไป HTTPS
- ป้องกันการดักจับและการสอดแนมเนื้อหาที่ไม่เข้ารหัส
X-Content-Type-Options และ X-Frame-Options - ป้องกัน MIME Sniffing และ Clickjacking
X-Content-Type-Options: nosniff บอกให้เบราว์เซอร์เชื่อถือ Content-Type header ที่คุณระบุและไม่พยายามเดาประเภทไฟล์ด้วยตัวเอง ไม่มี header นี้ เบราว์เซอร์จะอ่านไฟล์และอาจตัดสินว่ามันเป็น HTML แม้ว่าคุณกำหนดให้เป็น plain text X-Frame-Options: DENY ป้องกันเว็บไซต์ของคุณจากการถูกฝังใน iframe โดยไซต์อื่น โจมตี clickjacking จะพยายามให้ผู้ใช้คลิกที่ปุ่มซ่อนอยู่ด้านล่าง
- X-Content-Type-Options: nosniff ป้องกัน MIME sniffing attacks
- X-Frame-Options: DENY ป้องกัน clickjacking โดยสิ้นเชิง
- X-Frame-Options: SAMEORIGIN อนุญาต iframe จากไซต์เดียวกันเท่านั้น
- X-Frame-Options: ALLOW-FROM uri (deprecated) ระบุไซต์อื่นๆ ที่ได้รับอนุญาตบางไซต์
- ทั้งสอง headers นี้ใช้งานง่ายแต่มีประสิทธิภาพสูงมากในการป้องกันการโจมตีที่พบบ่อย
Referrer-Policy และ Permissions-Policy - ควบคุมข้อมูลอ้างอิงและสิทธิ์อนุญาต
Referrer-Policy ควบคุมว่าข้อมูล referer (URL ของหน้าที่ผู้ใช้มาจาก) ถูกส่งไปยังเว็บไซต์อื่นได้มากน้อยเพียงใด ตัวอย่างเช่น strict-origin-when-cross-origin จะส่งเฉพาะชื่อโดเมนเท่านั้น ไม่ใช่ URL เต็มหรือพารามิเตอร์ Permissions-Policy (เดิมชื่อ Feature-Policy) ควบคุมว่า scripts และ third-party iframes สามารถเข้าถึง API ของเบราว์เซอร์เช่น camera, microphone, location, payment request ได้หรือไม่
- Referrer-Policy: strict-origin-when-cross-origin ส่งเฉพาะต้นทาง
- Referrer-Policy: no-referrer ปิดการส่งข้อมูล referer ทั้งหมด
- Referrer-Policy: same-origin ส่ง referer เฉพาะในไซต์เดียวกัน
- Permissions-Policy: camera=() ปิดการเข้าถึง camera
- Permissions-Policy: geolocation=() ปิดการเข้าถึง location
- Permissions-Policy: payment=() ปิดการเข้าถึง payment API
วิธีเพิ่ม Security Headers - ตัวอย่าง Apache .htaccess และ Nginx
การเพิ่ม headers ลงในไซต์ของคุณนั้นง่าย ถ้าใช้ Apache ให้เพิ่มโค้ด .htaccess ที่กล่าวถึงในไดเรกทอรี่รูท ถ้าใช้ Nginx ให้แก้ไขไฟล์ nginx.conf หรือไฟล์เสิร์ฟเวอร์เสมือน (virtual server) หากใช้ PHP คุณสามารถเพิ่มได้ในโค้ด PHP ด้วย header() function เริ่มต้นด้วย headers ง่ายๆ เช่น X-Content-Type-Options และ X-Frame-Options แล้วค่อยๆ เพิ่ม CSP ซึ่งซับซ้อนกว่า
- Apache: ใช้
ในไฟล์ .htaccess - Nginx: เพิ่ม header directives ในเสิร์ฟเวอร์บล็อก
- PHP: ใช้ header() ฟังก์ชัน แต่ต้องอยู่ก่อนเอาต์พุต HTML
- เริ่มต้นด้วย simple headers ก่อนขยับไปที่ CSP
- ทดสอบใน report-only mode ก่อนที่จะบังคับใช้
- รีสตาร์ทเซิร์ฟเวอร์หรือโหลดไฟล์การตั้งค่าใหม่
ทดสอบ Headers ด้วยเครื่องมือสแกน Online
หลังจากตั้งค่า headers แล้ว ต้องทดสอบเพื่อให้แน่ใจว่าเบราว์เซอร์ได้รับมันจริงๆ มีเครื่องมือออนไลน์ฟรีหลายตัวที่ช่วยให้คุณสแกน headers และได้รับการจัดอันดับความปลอดภัย วิธีง่ายๆ คือเปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์และดูแท็บ Network แล้วตรวจสอบ Response headers ของไซต์คุณ หรือใช้เครื่องมือ curl ที่เป็นบรรทัดคำสั่ง
- ใช้เครื่องมือสแกนออนไลน์ฟรีเพื่อตรวจสอบ headers ทั้งหมด
- เปิดเครื่องมือสำหรับนักพัฒนา (F12) ดูแท็บ Network
- ดูเนื้อหา Response headers ในการโหลดหน้า
- ใช้คำสั่ง curl ผ่านเทอร์มินัล
- ตรวจสอบ Content-Security-Policy header errors ในคอนโซล
- ปรับปรุง header ถ้าทดสอบไม่ผ่าน
ความผิดพลาดทั่วไป CSP ที่ทำให้เว็บไซต์พัง
CSP ที่ตั้งค่าอย่างหนักเกินไปมักจะทำให้บางส่วนของเว็บไซต์พัง เช่น scripts ที่ไม่โหลด stylesheets ที่ไม่ใช้ หรือ iframes ที่ไม่แสดงผล ข้อผิดพลาดทั่วไป ได้แก่ การลืมอนุญาตโดเมนของ CDN สาธารณะใน script-src การลืมอนุญาต data: URLs สำหรับรูปภาพที่เข้ารหัส base64 หรือการใช้ 'unsafe-inline' ซึ่งลดความปลอดภัย ตัวอย่างที่ดี: เมื่อคุณมีปัญหา ให้เปิด report-only mode ดูข้อผิดพลาดในคอนโซล แล้วทำให้ CSP อ่านง่ายขึ้นเรื่อยๆ
- ลืมเพิ่ม CDN โดเมนใน script-src
- ใช้ 'unsafe-inline' ซึ่งลดความปลอดภัย
- ไม่อนุญาต data: URLs สำหรับ images หรือ fonts
- ปิด default-src ทั้งหมด แต่ลืม style-src
- ใช้ report-only mode เพื่อวินิจฉัยปัญหาก่อนบังคับใช้
- ตรวจสอบคอนโซล console เพื่อหา CSP violations
- ค่อยๆ เพิ่มความเข้มงวดของ policy ทีละขั้น แทนที่จะผ่อนคลายเร็วเกินไป
Security Headers เทียบกับ SSL Certificate - แต่ละตัวป้องกันอะไร
SSL certificates และ security headers เป็นชั้นความปลอดภัยที่แตกต่างกัน SSL certificate เข้ารหัส traffic ระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ ป้องกัน eavesdropping และ man-in-the-middle attacks ในระดับการส่งสัญญาณ Security headers ทำงานหลังจากการส่งข้อมูลได้รับอย่างปลอดภัยแล้ว โดยบอกให้เบราว์เซอร์ป้องกัน XSS, CSRF, clickjacking และ feature abuse คุณต้องมีทั้งคู่: SSL สำหรับการเข้ารหัส security headers สำหรับการป้องกันปัญหาที่เกี่ยวข้องกับแอปพลิเคชัน
- SSL Certificate เข้ารหัส data in transit ไม่ให้ถูกดักจับ
- Security Headers ป้องกัน application-level attacks เช่น XSS
- SSL ป้องกัน eavesdropping ของ ISP หรือ wi-fi networks
- CSP ป้องกัน injection attacks แม้ว่า SSL ปกป้องไป
- HSTS บังคับใช้ HTTPS แต่ไม่สามารถแก้ไข vulnerable code
- ต้องมี SSL + Security Headers ทั้งสองอย่างสำหรับความปลอดภัยเต็มที่
คำถามที่พบบ่อย (FAQ)
Security Headers มีผลต่อ SEO ranking หรือไม่
ไม่มีผลโดยตรง แต่ headers ที่ดีเช่น HSTS อาจช่วยลดปัญหา redirect chain ซึ่งถือว่าดีสำหรับ SEO CSP และ headers อื่นๆ เป็นส่วนหนึ่งของ site security ที่เสิร์ชเอนจิน (หลักๆ คือ Google) อาจให้ความสำคัญในการจัดอันดับเล็กน้อยเมื่อเปรียบเทียบเว็บไซต์ที่คล้ายคลึงกัน ความสำคัญหลักคือความปลอดภัยของผู้ใช้ และ SEO benefit จะตามมาเอง
การเพิ่ม CSP จะทำให้เว็บไซต์ของฉันพังได้หรือไม่
ได้ ถ้าคุณตั้งค่ามันผิดพลาด นั่นคือเหตุผลที่ต้องเริ่มด้วย report-only mode ซึ่งจะแจ้งคุณถึง violations โดยไม่ปิดกั้น scripts จริงๆ หลังจากตรวจสอบ console log และปรับปรุง header แล้ว ให้เปลี่ยนเป็น enforce mode ใช้วิธีขั้นตอนนี้ คุณจะหลีกเลี่ยงการสร้างเว็บไซต์ที่ไม่สามารถใช้งานได้
ความแตกต่างระหว่าง HSTS กับ SSL Certificate คืออะไร
SSL Certificate เข้ารหัส traffic ในระดับการส่งสัญญาณ (transport layer) HSTS บอกให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS เสมอ SSL Certificate เป็นสิ่งที่มีความจำเป็นตั้งแต่ต้นเพื่อให้ HSTS ทำงาน คุณต้องมี SSL Certificate ที่ถูกต้องก่อน จึงจะสามารถใช้ HSTS บอกให้เบราว์เซอร์อยู่ที่ HTTPS ได้
ฉันจะทดสอบว่า Security Headers ของฉันทำงานได้หรือไม่
วิธีที่ง่ายที่สุดคือเปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ (F12) ไปที่แท็บ Network โหลดหน้าเว็บ และดูส่วน Response headers คุณจะเห็น Content-Security-Policy, Strict-Transport-Security และ headers อื่นๆ ที่คุณตั้งค่าไว้ มีเครื่องมือออนไลน์ฟรีที่สแกน headers ทั้งหมดและให้คะแนนความปลอดภัยแก่คุณด้วย
Security Headers ทำให้ความเร็วหน้าเว็บลดลงหรือไม่
ไม่ ส่วนใหญ่แล้ว Headers เป็นเพียงคำสั่งข้อความง่ายๆ ที่ไม่ต้องใช้ทรัพยากรเพิ่มเติม แม้แต่ CSP ที่ซับซ้อนก็ส่งผลต่อ browser ไม่ใช่ server performance ประโยชน์ด้านความปลอดภัยมีมากกว่าค่าใช้จ่ายด้านประสิทธิภาพมาก แม้ว่า HSTS อาจช่วยลด redirect chains ได้ ซึ่งจริงๆ แล้วจะช่วยเร่งเพจขึ้น