วิธีเพิ่ม HTTP Security Headers ใน WordPress

WordPress เป็นระบบจัดการ เนื้อหา (CMS) ที่ได้รับความนิยมมากที่สุดในโลก ซึ่งใช้งานมากกว่า43% ของเว็บไซต์ทั้งหมดบนอินเทอร์เน็ตอย่างไรก็ตาม การใช้งานอย่างแพร่หลายทำให้เป็นเป้าหมายทั่วไปสำหรับแฮ็กเกอร์

การโจมตีด้วยกำลังดุร้าย ช่องโหว่ในการอัปโหลดไฟล์ และการโจมตีด้วยสคริปต์ข้ามไซต์ ล้วนมีส่วนทำให้เกิดภัยคุกคามอย่างต่อเนื่อง

โชคดีที่มีหลายวิธีในการทำให้เว็บไซต์ของคุณปลอดภัยขึ้นและเสี่ยงต่อการถูกโจมตีน้อยลง และนั่นคือที่มาของ HTTP Headers ในรูปภาพ

ด้วยการใช้ HTTP Security Headers คุณสามารถจำกัดการดำเนินการที่เบราว์เซอร์และเซิร์ฟเวอร์สามารถดำเนินการบนเว็บไซต์ของคุณ และเพิ่มความปลอดภัยอีกชั้นหนึ่งได้ ส่วนหัวเหล่านี้ทำให้ผู้โจมตีใช้ประโยชน์จากช่องโหว่ฝั่งไคลเอ็นต์ได้ยากขึ้นมาก

ในบทความนี้ เราจะพูดถึง ว่าส่วนหัวของการรักษาความปลอดภัย HTTP คืออะไร และคุณจะนำไปใช้กับเว็บไซต์ของคุณอย่างมีประสิทธิภาพได้อย่างไร

HTTP Security Headers คืออะไรกันแน่?

HTTP Security Headers เป็นกลุ่มคำสั่งที่ใช้โดยเว็บแอปพลิเคชันเพื่อใช้การป้องกันความปลอดภัยในเว็บเบราว์เซอร์ ส่วนหัวเหล่านี้มีการแลกเปลี่ยนระหว่างเว็บเบราว์เซอร์ (ไคลเอนต์) และเซิร์ฟเวอร์เพื่อระบุพารามิเตอร์ความปลอดภัยของการสื่อสาร HTTP การแลกเปลี่ยนข้อมูลนี้จะบอกเบราว์เซอร์ว่าควรทำงานอย่างไรตลอดการโต้ตอบกับไซต์ของคุณ และควบคุมกระบวนการต่างๆ เช่น การแสดงข้อผิดพลาดและการจัดการแคช

แน่นอนว่าความปลอดภัยและประสิทธิภาพเพิ่มเติมนี้ขึ้นอยู่กับเบราว์เซอร์เป็นส่วนใหญ่ เว็บเบราว์เซอร์รุ่นเก่าจะไม่มีความปลอดภัยหรือความเข้ากันได้ในระดับเดียวกัน และอาจประมวลผลส่วนหัวความปลอดภัย HTTP ไม่ถูกต้อง สมบูรณ์ หรือแม้แต่ไม่ได้เลย ซึ่งอาจหมายความว่า แม้ว่าคุณพยายามอย่างเต็มที่แล้วในการช่วยให้ผู้เข้าชมปลอดภัย เบราว์เซอร์ที่ล้าสมัยของพวกเขาก็ยังปล่อยให้พวกเขามีความเสี่ยง ในฐานะนักพัฒนาเว็บไซต์ เราควรทำทุกอย่างที่ทำได้ แต่ยอมรับว่าในท้ายที่สุดแล้วผู้เยี่ยมชมเป็นความรับผิดชอบของพวกเขาที่จะต้องแน่ใจว่าพวกเขากำลังใช้ซอฟต์แวร์ที่ทันสมัยในคอมพิวเตอร์ของตน ตราบใดที่พวกเขาใช้เว็บเบราว์เซอร์ที่ทันสมัยและทันสมัย ​​การใช้ส่วนหัวความปลอดภัย HTTP ของเราจะทำงานร่วมกับซอฟต์แวร์เบราว์เซอร์ของพวกเขาเพื่อรักษาความปลอดภัย

อย่างไรก็ตาม ข้อกังวลหลักของเราคือส่วนหัวความปลอดภัย HTTP ป้องกันเว็บไซต์ของคุณจากการโจมตีทั่วไป เช่น การเขียนสคริปต์ข้ามไซต์และการโจมตีแบบเดรัจฉานวิธีที่มีประสิทธิภาพที่สุดในการนำส่วนหัวเหล่านี้ไปใช้คือการตั้งค่าให้เป็นบัญชีโฮสติ้ง WordPress ของคุณ (ระดับเซิร์ฟเวอร์) และใช้ไฟร์วอลล์แอปพลิเคชันเว็บไซต์ระดับ DNS เช่น Cloudflare

แต่คุณต้องจำไว้ว่าการเพิ่มส่วนหัวความปลอดภัย HTTP สามารถช่วยปรับปรุงความปลอดภัยของไซต์ของคุณได้ แต่เป็นเพียงแง่มุมหนึ่งของความปลอดภัยของเว็บไซต์และควรใช้ร่วมกับมาตรการรักษาความปลอดภัยอื่นๆ ซึ่งรวมถึงการอัปเดตแอปพลิเคชันและปลั๊กอินของคุณ การเข้ารหัสข้อมูลที่ละเอียดอ่อนของคุณ และการสำรองข้อมูลไซต์และไฟล์การกำหนดค่า

ก่อนที่จะพูดถึงวิธีการต่างๆ ในการเพิ่มส่วนหัวของการรักษาความปลอดภัย เรามาดูรายละเอียดแต่ละส่วนหัวและทำความเข้าใจว่าเหตุใดจึงมีความสำคัญหากคุณคุ้นเคยกับส่วนหัวของการรักษาความปลอดภัยแล้ว คุณสามารถข้ามไปยังส่วนด้านล่างได้

ประเภทของส่วนหัว WordPress HTTP Security

มีส่วนหัวการรักษาความปลอดภัย HTTP หลายรายการที่สามารถใช้กับเว็บไซต์ WordPress ของคุณเพื่อเพิ่มการป้องกัน ลองมาดูสิ่งที่สำคัญที่สุด

1. ส่วนหัวของ X-XSS Protection Security

ส่วนหัวด้านความปลอดภัยนี้ใช้เพื่อกำหนดค่าการเขียนสคริปต์ข้ามไซต์ (XSS) ซึ่งเป็นช่องโหว่ด้านความปลอดภัยที่อนุญาตให้บุคคลที่สามที่ไม่ผ่านการรับรองความถูกต้องสามารถ รันโค้ดในนามของเว็บไซต์อื่น ในเบราว์เซอร์ได้

ป้องกันการโจมตี XSS จำนวนมากบนเว็บไซต์ของคุณโดยการหยุดการแสดงผลเว็บไซต์หากตรวจพบการโจมตี X-XSS ใช้ตัวเลือกที่ปลอดภัยกว่าในการไม่โหลดไซต์ทั้งหมด แทนที่จะพยายามฆ่าเชื้อหน้าเว็บด้วยการแทนที่องค์ประกอบที่อาจเป็นอันตราย

ส่วนหัวสามารถมีค่าใดค่าหนึ่งต่อไปนี้:

• X-XSS-Protection: 0 ปิดใช้งานการกรอง XSS (ไม่แนะนำ)
• X-XSS-Protection: 1 เปิดใช้งานการกรอง XSS ซึ่งโดยปกติจะเป็นค่าเริ่มต้นในเบราว์เซอร์ส่วนใหญ่ หากตรวจพบการโจมตี XSS เบราว์เซอร์จะลบส่วนที่ไม่ปลอดภัยของหน้าออก (ฆ่าเชื้อ)
• X-XSS-การป้องกัน: 1; mode=block เปิดใช้งานการกรอง XSS แต่แทนที่จะทำให้หน้าสะอาด เบราว์เซอร์จะป้องกันการแสดงผลของหน้า (แนะนำ)
• X-XSS-การป้องกัน: 1; รายงาน=<รายงาน-uri> เปิดใช้งานการกรอง XSS เบราว์เซอร์จะทำความสะอาดหน้าเว็บและรายงานการละเมิดหากตรวจพบการโจมตีแบบสคริปต์ข้ามไซต์

2. ส่วนหัวความปลอดภัยของตัวเลือก X-Frame

สามารถใช้ส่วนหัวการรักษาความปลอดภัย X-Frame-Options เพื่อ ป้องกันการโจมตีแบบ brute force และการโจมตี DDOS ที่แตกต่างกัน แต่การใช้งานที่มีประสิทธิภาพสูงสุดคือการต่อต้าน iframe แบบ cross-jacking และ click-jacking บนเว็บไซต์ WordPress ของคุณส่วนหัวนี้ช่วยให้คุณตัดสินใจได้ว่าจะสามารถฝังหน้าบนเว็บไซต์ของคุณโดยใช้องค์ประกอบ iframe ในเบราว์เซอร์ได้หรือไม่

X-Frame Option ปกป้องเว็บไซต์ของคุณจากการโจรกรรมคลิกโดยหยุด iframes ไม่ให้เติมเต็มไซต์ของคุณ มีสองคำสั่งที่แตกต่างกันซึ่งคุณสามารถเลือกได้ –DENY และ SAMEORIGINใช้งานได้กับเว็บเบราว์เซอร์ยอดนิยมทั้งหมด เช่น Chrome, Safari, Firefox และ Opera

 X-Frame-Options: ปฏิเสธ

 ตัวเลือก X-Frame: SAMEORIGIN

เมื่อระบุด้วย DENY ส่วนหัว X-Frame-Options จะทำให้เกิดความล้มเหลว หากเบราว์เซอร์ใดๆ พยายามโหลดหน้าเว็บภายในเฟรมเมื่อโหลดจากไซต์อื่น ความพยายามในการทำเช่นนี้จะล้มเหลวเมื่อโหลดลงใน iframe จากไซต์ดั้งเดิม ในทางกลับกัน หากเราระบุ SAMEORIGIN เรายังคงสามารถใช้เพจภายในเฟรมได้ ตราบใดที่ไซต์ที่รวมอยู่ในเฟรมนั้นเหมือนกับไซต์ที่ให้บริการเพจนั้น

ส่วนหัวนี้มีความสำคัญอย่างยิ่งสำหรับหน้าเว็บที่มีข้อมูลที่ละเอียดอ่อนและหน้าที่ฝังข้อมูล เช่น เกตเวย์การชำระเงินและแบบฟอร์ม

3. ส่วนหัว HTTP Strict Transport Security (HSTS)

HTTP Strict-Transport-Security คือส่วนหัวการตอบสนองด้านความปลอดภัยที่ส่งจากเว็บเซิร์ฟเวอร์ไปยังเว็บเบราว์เซอร์ของผู้ใช้เพื่อแจ้งให้ทราบว่าไซต์ควรเข้าถึงได้โดยใช้ HTTP เท่านั้น และไม่ควรผ่าน HTTP ที่ไม่ได้เข้ารหัส

ส่วนหัวนี้มีกลไกในการ บังคับใช้ HTTPS โดยเบราว์เซอร์ แม้ว่าผู้ใช้จะพิมพ์ “http://” ในแถบที่อยู่หรือตามลิงก์ HTTP ก็ตามนอกจากนี้ยังสามารถป้องกันไม่ให้ผู้ใช้เพิกเฉยต่อใบรับรอง SSL/TLS ที่หมดอายุหรือไม่ถูกต้องและคำเตือนอื่นๆ ของเบราว์เซอร์ ค่า HSTS ถูกตั้งค่าตามเบราว์เซอร์ที่เข้าชมเว็บไซต์ ไม่ได้ตั้งค่าต่อเครื่อง

ส่วนหัว HSTS ให้ตัวเลือกในการรวมโดเมนย่อยใดๆ คุณสามารถใช้คำสั่ง "includeSubDomains" เพื่อปรับใช้การรักษาความปลอดภัยในระดับเดียวกันจากโดเมนหลัก ซึ่งหมายความว่าการพัฒนาในเครื่องใดๆ ด้วยโดเมน (หรือโดเมนย่อย) จะไม่สามารถเข้าถึงได้ผ่าน HTTP เนื่องจากเบราว์เซอร์จะอนุญาตการรับส่งข้อมูล HTTPS เท่านั้น

ตัวอย่างเช่น หากคุณมีส่วนหัว HSTS บน example.com ที่มีคำสั่ง “includeSubdomains ” ที่จำเป็น คุณจะไม่สามารถเข้าถึงโดเมนย่อยของ example.com ผ่านการเชื่อมต่อที่ไม่ปลอดภัยได้เมื่อคุณเยี่ยมชม example.com แล้ว ดังนั้น โปรดระวังหากคุณเลือกใช้ “includeSubdomains” ซึ่งอาจมีผลกระทบต่อโดเมนอื่นๆ ของคุณ

เมื่อเบราว์เซอร์ได้รับส่วนหัว HSTS จากไซต์ เบราว์เซอร์จะจดจำนโยบาย HSTS ตามระยะเวลาที่กำหนด และอัปเกรดคำขอในอนาคตทั้งหมดไปยังไซต์เป็น HTTPS โดยอัตโนมัติ ซึ่งช่วยในการหลีกเลี่ยงการโจมตีจากคนกลาง การดักฟัง และการแทรกแซงรูปแบบอื่นๆ โดยทำให้มั่นใจว่าการสื่อสารทั้งหมดระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ได้รับการเข้ารหัส

ไวยากรณ์สำหรับส่วนหัวนี้คือ:

 # ไม่มีคำสั่ง includeSubDomains
<IfModule mod_headers.c>
ส่วนหัวตั้งค่าเข้มงวดการขนส่งความปลอดภัย: “อายุสูงสุด = 63072000;”
</หากโมดูล>
# ด้วยคำสั่ง includeSubDomains
<IfModule mod_headers.c>
ส่วนหัวตั้งค่า Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" 
</หากโมดูล>

คำสั่ง max-age=<expire-time> กำหนดเวลา (เป็นวินาที) ที่เบราว์เซอร์ควรจำไว้ว่าไซต์สามารถเข้าถึงได้โดยใช้ HTTPS เท่านั้น ตัวอย่างเช่น ในตัวอย่างข้างต้น อายุสูงสุด ถูกกำหนดเป็นสองปี หากคุณเลือกที่จะมี Servebolt CDN หรือ Accelerated Domains จาก Servbolt คุณจะมีเวลา HSTS 1 ปีโดยอัตโนมัติ

4. ส่วนหัวของนโยบายผู้อ้างอิง

ส่วนหัว HTTP นี้ควบคุมว่าควรรวมข้อมูลผู้อ้างอิงที่ส่งผ่านส่วนหัวผู้อ้างอิงมากน้อยเพียงใดในคำขอ โดยจะจำกัดจำนวนข้อมูลที่ส่งเมื่อผู้เยี่ยมชมไซต์คลิกลิงก์ ซึ่ง จะช่วยป้องกันการรั่วไหลของข้อมูลที่ละเอียดอ่อนไปยังเว็บไซต์อื่นๆ เช่น URL ของหน้าที่มีข้อมูลส่วนตัว

สามารถมีค่าได้หลายค่า นี่คือบทสรุปโดยย่อ:

• ไม่มีผู้อ้างอิง: ส่วนหัวผู้อ้างอิงจะไม่ถูกส่งไม่ว่าในกรณีใด ๆ
• ไม่มีผู้อ้างอิงเมื่อดาวน์เกรด: ส่วนหัวผู้อ้างอิงจะไม่ถูกส่งเมื่อนำทางจากไซต์ HTTPS ไปยังไซต์ HTTP
• ต้นทาง: ส่วนหัวผู้อ้างอิงจะรวมเฉพาะต้นทาง (โครงร่าง โฮสต์ และพอร์ต) ของหน้าที่อ้างอิงเท่านั้น
• ต้นทางเมื่อข้ามต้นทาง: ส่วนหัวผู้อ้างอิงจะรวม URL แบบเต็มของหน้าที่อ้างอิงเมื่อนำทางระหว่างหน้าต่างๆ ภายในต้นทางเดียวกัน และเฉพาะต้นทางเมื่อนำทางไปยังต้นทางอื่น
• ต้นทางที่เข้มงวด: ส่วนหัวผู้อ้างอิงจะรวมเฉพาะต้นทางของหน้าที่อ้างอิงเท่านั้น และจะไม่ถูกส่งไปสำหรับคำขอข้ามต้นทาง
• Strict-origin-when-cross-origin: ส่วนหัวผู้อ้างอิงจะรวมที่มาของหน้าอ้างอิงและจะไม่ถูกส่งไปสำหรับคำขอข้ามต้นทาง ยกเว้นสำหรับต้นทางจากไซต์เดียวกัน เราขอแนะนำให้ใช้การตั้งค่านี้เนื่องจากยังคงรักษาประโยชน์ของส่วนหัวไว้ในขณะที่ลดความเสี่ยงของการรั่วไหลของข้อมูล
• URL ที่ไม่ปลอดภัย: ส่วนหัวผู้อ้างอิงจะส่งต้นทาง เส้นทาง และสตริงข้อความค้นหาเมื่อดำเนินการตามคำขอใดๆ โดยไม่คำนึงถึงความปลอดภัย

สำหรับการสนทนาเชิงลึกเกี่ยวกับส่วนหัวของนโยบายผู้อ้างอิง โปรดอ่านบทความของ Google web.dev เกี่ยวกับ แนวทาง ปฏิบัติที่ดีที่สุดสำหรับนโยบายผู้อ้างอิง

5. ส่วนหัว X-Content-Type-Options

เซิร์ฟเวอร์ส่งส่วนหัว X-Content-Type-Options ในการตอบสนอง HTTP เพื่อระบุเบราว์เซอร์เกี่ยวกับประเภท MIME จุดประสงค์ของส่วนหัวนี้คือเพื่อ ป้องกันไม่ให้เบราว์เซอร์ตีความไฟล์เป็นประเภท MIME ที่แตกต่าง จากที่ระบุไว้ในส่วนหัว

ส่วนหัวนี้สามารถมีค่า "nosniff" ได้ค่าเดียว ไวยากรณ์เป็นดังนี้:

 X-Content-Type-Options: ไร้สาระ

มีประสิทธิภาพมากในการโจมตีด้วยความสับสนของ MIME - การใช้ส่วนหัวความปลอดภัยนี้สามารถป้องกันเบราว์เซอร์จากการตีความไฟล์ในลักษณะที่ไม่คาดคิดซึ่งอาจนำไปสู่ช่องโหว่ด้านความปลอดภัย ตัวอย่างเช่น หากผู้โจมตีอัปโหลดไฟล์ที่มีนามสกุล .jpg แต่ไม่มีเนื้อหาเนื่องจากแท้จริงแล้วเป็นสคริปต์ การตั้งค่าส่วนหัว X-Content-Type-Options เป็น "nosniff" จะไม่อนุญาตให้เบราว์เซอร์เรียกใช้สคริปต์ จึงปกป้องผู้ใช้จากการละเมิดที่อาจเกิดขึ้น

6. ส่วนหัว ของนโยบายความปลอดภัยของเนื้อหา(CSP)

Content-Security-Policy คือส่วนหัวความปลอดภัยที่ใช้ระบุที่มาของเนื้อหาและจัดเตรียมกลไกสำหรับเนื้อหาที่อนุญาตให้โหลดและดำเนินการในเว็บไซต์หรือเว็บแอปพลิเคชัน ด้วยการระบุชุดของนโยบาย ส่วนหัวนี้สามารถจำกัดประเภทของเนื้อหาที่อนุญาตบนหน้าเว็บ และลดภัยคุกคามความปลอดภัยประเภทต่างๆ เป็นการรักษาความปลอดภัยอีกชั้นหนึ่งเพื่อป้องกันการโจมตีแบบ Cross-Site Scripting (XSS) และการฉีดข้อมูลที่ใช้สำหรับอาชญากรรม เช่น การขโมยข้อมูล การทำให้เว็บไซต์เสียหาย และการกระจายมัลแวร์

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

ต้องกำหนดค่าเซิร์ฟเวอร์ให้ส่งคืนส่วนหัว Content-Security-Policy เพื่อให้นโยบายทำงานได้ คุณสามารถใช้ส่วนหัว CSP HTTP เพื่อระบุนโยบายของคุณดังนี้:

 นโยบายความปลอดภัยเนื้อหา: นโยบาย

นโยบายนี้เป็นสตริงที่มีคำสั่งนโยบายที่อธิบายถึงนโยบายความปลอดภัยของเนื้อหาของคุณ ตัวอย่างเช่น คุณสามารถเพิ่มบรรทัดต่อไปนี้ในไฟล์ .htaccess เพื่อใช้งาน CSP

 <IfModule mod_headers.c>
ส่วนหัวตั้งค่านโยบายความปลอดภัยเนื้อหา "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
</หากโมดูล>

หากคุณบังคับใช้ CSP บนเว็บไซต์ WordPress คุณควรทราบว่า WordPress จำเป็นต้องใช้ 'unsafe-inline' และ 'unsafe-eval' เพื่อให้ทำงานได้อย่างถูกต้อง การกำหนดค่าข้างต้นเป็นจุดเริ่มต้นที่ดีสำหรับเว็บไซต์ WordPress ส่วนใหญ่ อย่างไรก็ตาม มีความเสี่ยงที่เกี่ยวข้องกับการใช้การกำหนดค่าข้างต้นโดยไม่เข้าใจความหมายของแต่ละส่วนอย่างชัดเจน นี่คือรายละเอียดของแต่ละคำสั่ง:

• default-src – คำสั่งนี้ตั้งค่านโยบายเริ่มต้นสำหรับทรัพยากรทุกประเภท เว้นแต่จะถูกแทนที่ด้วยคำสั่งอื่นในกรณีนี้ จะอนุญาตให้โหลดทรัพยากรจากต้นทางเดียวกัน ('ตัวเอง') รวมถึงจากแหล่ง HTTPS และจากสคริปต์ที่ใช้ 'unsafe-eval' หรือ 'unsafe-inline'
• object-src – คำสั่งนี้จำกัดประเภทของอ็อบเจกต์ที่สามารถฝังในเพจ เช่น Flash หรือ Java appletที่นี่อนุญาตให้โหลดวัตถุจากแหล่งกำเนิดเดียวกันเท่านั้น ('ตัวเอง')
• font-src – คำสั่งนี้จำกัดแหล่งที่มาของแบบอักษรที่สามารถโหลดได้ที่นี่ อนุญาตให้โหลดฟอนต์จากแหล่ง HTTPS, โครงร่าง URI ข้อมูล และจากต้นทางเดียวกัน ('ตัวเอง') หรือจากแหล่ง HTTP จาก Google Fonts และเนื้อหาผู้ใช้ Google
• connect-src – คำสั่งนี้จำกัดแหล่งที่มาที่สามารถใช้สำหรับคำขอเครือข่าย เช่น คำขอ AJAX หรือ WebSocketsที่นี่อนุญาตให้ทำการเชื่อมต่อผ่าน HTTPS หรือ WebSockets และจากต้นทางเดียวกันเท่านั้น ('ตัวเอง')
• img-src – คำสั่งนี้จำกัดแหล่งที่มาของรูปภาพที่สามารถโหลดได้ที่นี่ อนุญาตให้โหลดรูปภาพจากแหล่ง HTTPS, รูปแบบ URI ข้อมูล และจากต้นทางเดียวกัน ('ตัวเอง') หรือจากแหล่ง HTTP จาก Gravatar
• worker-src – คำสั่งนี้จำกัดแหล่งที่สามารถโหลดผู้ปฏิบัติงานบนเว็บได้ที่นี่อนุญาตให้โหลดผู้ปฏิบัติงานจากแบบแผน URI blob, แหล่งที่มา HTTPS และจากสคริปต์ที่ใช้ 'unsafe-eval' หรือ 'unsafe-inline' เท่านั้น
• media-src – คำสั่งนี้จำกัดแหล่งข้อมูลที่สามารถโหลดทรัพยากรสื่อ เช่น เสียงหรือวิดีโอที่นี่อนุญาตให้โหลดสื่อจากแหล่งที่มา HTTPS, โครงร่าง URI blob และจากต้นทางเดียวกันเท่านั้น ('ตัวเอง')
• style-src – คำสั่งนี้จำกัดแหล่งที่มาของสไตล์ชีตที่สามารถโหลดได้ที่นี่ อนุญาตให้โหลดสไตล์จากแหล่งที่มา HTTPS และจากสคริปต์ที่ใช้ 'unsafe-eval' หรือ 'unsafe-inline' รวมทั้งจากต้นทางเดียวกัน ('self') และจากแหล่ง HTTP จาก Google Fonts

เมื่อใช้ส่วนหัว CSP กับอินสแตนซ์ WordPress ของคุณ สิ่งสำคัญคือต้องทราบว่าการใช้ส่วนหัว CSP อย่างไม่เหมาะสมจะทำให้แดชบอร์ดผู้ดูแลระบบ WordPress เสียหาย เนื่องจากปลั๊กอินและบริการบางอย่างอาจใช้ JavaScript ของบุคคลที่สาม

ในการแก้ไขปัญหานี้ คุณจะต้องเพิ่มกฎความปลอดภัยแต่ละข้อลงในไฟล์ส่วนหัวด้วยตนเอง อีกทางเลือกหนึ่งแต่ปลอดภัยน้อยกว่าคือการปิดใช้งานส่วนหัว CSP ในแดชบอร์ดผู้ดูแลระบบของคุณ ตัวอย่างเช่น นี่คือสิ่งที่เราทำบน servebolt.com :

 ส่วนหัวตั้งค่า X-Frame-Options SAMEORIGIN
ส่วนหัวกำหนดนโยบายผู้อ้างอิงที่เข้มงวดต้นทางเมื่อข้ามต้นทาง
ส่วนหัวตั้งค่า X-XSS-Protection "1; mode=block"
<หาก "%{REQUEST_URI} !~ /wp-admin/">
# เพิ่มเฉพาะส่วนหัวหากไม่ใช่หน้าจอผู้ดูแลระบบ
ส่วนหัวตั้งค่านโยบายความปลอดภัยเนื้อหาเสมอ "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.com servebolt.containers .piwik.pro *.intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.net servebolt.piwik.pro ; media-src 'self' *.intercomcdn.com data: ; img -src 'ตัวเอง' 'ไม่ปลอดภัยในบรรทัด' *.intercom.io *.intercomcdn.com *.intercomassets.com ข้อมูล: raskesider.raskesider.no *.servebolt.com secure.gravatar.com servebolt.piwik.pro ; connect- src 'self' ws: nexus-websocket-a.intercom.io *.piwik.pro servebolt.piwik.pro *.intercom.io ; font-src 'self' *.intercomcdn.com ข้อมูล: ; frame-src 'self ' app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; frame-ancestors 'self' *.servebolt com;manifest-src 'ตัวเอง' ;"
</หาก>

ในขณะที่บังคับใช้ CSP บนไซต์ของคุณ คุณควรทราบว่าอาจทำให้สภาพแวดล้อมการพัฒนาของคุณเสียหายหากคุณไม่ได้ใช้ HTTPS หากคุณไม่แน่ใจว่าจะ สร้าง นโยบายสำหรับไซต์ของคุณอย่างไร คุณควรใช้เครื่องมือกราฟิก เช่น ValidBot – CSP Wizard หรือ Report URI: CSP generator

7. สิทธิ์ - ส่วนหัวของนโยบาย

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

นโยบายสิทธิ์อนุญาตให้เซิร์ฟเวอร์ตั้งค่าว่าสามารถใช้คุณสมบัติในเอกสารใดเอกสารหนึ่งได้หรือไม่ มันใช้รายการที่อนุญาต – รายการของต้นทางที่รับค่าที่กำหนดไว้ล่วงหน้าโดยเฉพาะค่าของส่วนหัว Permission-Policy ประกอบด้วยรายการชื่อคำสั่งที่คั่นด้วยเครื่องหมายจุลภาค และค่าที่อธิบายสิทธิ์ต่างๆ ที่เว็บไซต์ต้องการ

ไวยากรณ์ทั่วไปสำหรับส่วนหัวนโยบายสิทธิ์คือ:

 นโยบายสิทธิ์: <directive>=<allowlist>

ตัวอย่างเช่น หากเราต้องการบล็อกการเข้าถึงตำแหน่งทางภูมิศาสตร์ทั้งหมด เราจะทำดังนี้

 นโยบายการอนุญาต: ตำแหน่งทางภูมิศาสตร์ = ()

ที่นี่ สัญลักษณ์ () หมายถึงรายการที่อนุญาตว่างเปล่า ในการอนุญาตให้เข้าถึงส่วนย่อยของต้นทาง เราจะทำดังนี้

 <IfModule mod_headers.c>
ส่วนหัวตั้งค่าสิทธิ์นโยบายเสมอ "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), ไจโรสโคป=(), เครื่องวัดสนามแม่เหล็ก=(), กล้อง=(), ไมโครโฟน=(), เต็มหน้าจอ=(ตัวเอง)"
</หากโมดูล>

ลองมาอีกตัวอย่างหนึ่ง ค่าส่วนหัวต่อไปนี้จำกัดเว็บไซต์ให้ดำเนินการสคริปต์เท่านั้น หากให้บริการจากต้นทางเดียวกันกับเอกสารหลัก:

 สิทธิ์-นโยบาย: script-src 'ตัวเอง'

สามารถใช้ส่วนหัว Permissions-Policy เพื่อแทนที่หรือเสริมส่วนหัว Content-Security-Policy แบบดั้งเดิม ซึ่งมีการทำงานที่คล้ายคลึงกัน แต่มีรูปแบบที่แตกต่างกันและมีความครอบคลุมน้อยกว่าในแง่ของสิทธิ์ปัจจุบันส่วนหัวนี้เป็นเทคโนโลยีทดลอง ที่รองรับเฉพาะใน Google Chrome และเบราว์เซอร์ที่ใช้ Chromium อื่นๆมีกลไกที่มีประสิทธิภาพและยืดหยุ่นมากขึ้นในการควบคุมสิทธิ์ และคาดว่าจะมีการใช้งานเพิ่มมากขึ้นในอนาคต หากคุณต้องการลองใช้ด้วยตัวคุณเอง คุณสามารถใช้ Permission Policy Header Generator เพื่อสร้างนโยบายการอนุญาตได้อย่างง่ายดาย

การเพิ่ม HTTP Security Headers โดยใช้ไฟล์ .htaccess

วิธีที่เราแนะนำให้เพิ่มส่วนหัวความปลอดภัย HTTP คือการแก้ไข ไฟล์ .htaccessโดยตรง นี่คือไฟล์การกำหนดค่าเซิร์ฟเวอร์ที่ใช้บ่อยที่สุดโดยเว็บเซิร์ฟเวอร์ Apache การแก้ไขไฟล์นี้ทำให้คุณมั่นใจได้ว่าส่วนหัวความปลอดภัย HTTP ใน WordPress ได้รับการกำหนดค่าที่ระดับเซิร์ฟเวอร์

คุณจะต้องเข้าถึง ไฟล์.htaccessของเว็บไซต์ของคุณ เพื่อใช้วิธีนี้ สามารถเข้าถึงได้บนเซิร์ฟเวอร์ Apache โดยใช้ไคลเอนต์ FTPก่อนทำการเปลี่ยนแปลงใดๆ ขอแนะนำให้คุณสำรองข้อมูล ไฟล์.htaccess ปัจจุบันของคุณ

ขั้นแรก เพียงลงชื่อเข้าใช้ไซต์ของคุณโดยใช้ไคลเอ็นต์ FTP หรือเครื่องมือจัดการไฟล์ในแผงควบคุมการโฮสต์ ในโฟลเดอร์รูทของเว็บไซต์ของคุณ ค้นหา ไฟล์.htaccessและคลิกขวาที่ตัวเลือก 'แก้ไข' จะเป็นการเปิดไฟล์ด้วยโปรแกรมแก้ไขข้อความหากต้องการเพิ่มส่วนหัวความปลอดภัย HTTPS ให้กับไซต์ของคุณ คุณสามารถเพิ่มรหัสที่เกี่ยวข้องที่ด้านล่างของ ไฟล์.htaccess

โค้ดตัวอย่างต่อไปนี้สามารถใช้เป็นจุดเริ่มต้นได้โดยจะตั้งค่าส่วนหัวความปลอดภัย HTTP ที่ใช้บ่อยที่สุดด้วยการตั้งค่าที่แนะนำ

 <IfModule mod_headers.c>
ส่วนหัวตั้งค่า Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
ส่วนหัวตั้งค่า X-XSS-Protection "1; mode=block"
ส่วนหัวตั้งค่า X-Content-Type-Options "nosniff"
ส่วนหัวตั้งค่า X-Frame-Options DENY
ส่วนหัวกำหนดนโยบายผู้อ้างอิง "ไม่มีผู้อ้างอิงเมื่อดาวน์เกรด"
ส่วนหัวตั้งค่านโยบายความปลอดภัยเนื้อหา "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
ส่วนหัวตั้งค่าสิทธิ์นโยบายเสมอ "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), ไจโรสโคป=(), เครื่องวัดสนามแม่เหล็ก=(), กล้อง=(), ไมโครโฟน=(), เต็มหน้าจอ=(ตัวเอง)"
</หากโมดูล>

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

คุณสามารถตรวจสอบว่ามีการใช้ส่วนหัวหรือไม่โดยเปิดแท็บ "เครือข่าย" ใน Chrome DevTools และตรวจสอบส่วนหัวการตอบสนองของคำขอของคุณ

หลังจากเพิ่มโค้ดแล้ว ให้บันทึกการเปลี่ยนแปลงและเยี่ยมชมเว็บไซต์ของคุณอีกครั้งเพื่อให้แน่ใจว่าทำงานได้ตามปกติ คุณต้องใช้ความระมัดระวังเมื่อแก้ไขไฟล์ .htaccess ของคุณ เนื่องจากส่วนหัวของรหัสที่ไม่ถูกต้องหรือการพิมพ์ ผิด อาจทำให้เกิดข้อผิดพลาด เช่น 500 Internal Server Error

การเพิ่ม HTTP Security Headers ใน WordPress โดยใช้ Content Distribution Network (CDN)

เครือข่ายการจัดส่งเนื้อหา (CDN) คือกลุ่มของเซิร์ฟเวอร์ที่กระจายตามพื้นที่ทางภูมิศาสตร์ที่ให้เนื้อหาอินเทอร์เน็ตที่แคชไว้จากตำแหน่งเครือข่ายที่ใกล้กับผู้ใช้มากที่สุดเพื่อปรับปรุงประสิทธิภาพของเว็บ CDN ยอดนิยม เช่น Cloudflareยังช่วยให้คุณเพิ่มส่วนหัว HTTP ลงในเว็บไซต์ของคุณได้อีกด้วย

ลองใช้ Cloudflare เป็นตัวอย่างและดูว่าเราจะเพิ่มส่วนหัว HTTP โดยใช้ CDN ได้อย่างไร Cloudflare เสนอไฟร์วอลล์เว็บไซต์ขั้นพื้นฐานฟรีพร้อมกับบริการ CDN แต่คุณสมบัติความปลอดภัยขั้นสูงนั้นถูกล็อคไว้หลังเพย์วอลล์

การตั้งค่า Cloudflare บนเว็บไซต์ WordPress ของคุณนั้นค่อนข้างง่าย คุณสามารถลงทะเบียนด้วยตนเองบนเว็บไซต์ของ Cloudflare และทำตามขั้นตอนบนหน้าจอเพื่อเปิดใช้งาน เมื่อเปิดใช้งาน Cloudflare บนเว็บไซต์ของคุณแล้ว ให้ตรงไปที่หน้า SSL/TLS ในแดชบอร์ดของบัญชี Cloudflare ของคุณ

จากนั้นคุณจะต้องเปลี่ยนไปที่แท็บ 'Edge Certificates' และค้นหาส่วน HTTP Strict Transport Security (HSTS) และคลิกที่ตัวเลือก 'Enable HSTS' หลังจากเปิดใช้งานปุ่ม 'เปิดใช้งาน HSTS' แล้ว หน้าต่างจะปรากฏขึ้นพร้อมคำแนะนำเพื่อช่วยคุณเปิดใช้งานคุณลักษณะนี้บนไซต์ของคุณ คลิกที่ปุ่ม 'ถัดไป' เพื่อดำเนินการต่อ และคุณจะเห็นตัวเลือกในการเพิ่มส่วนหัวความปลอดภัย HTTP

จากที่นี่ คุณสามารถเปิดใช้งาน HSTS บนไซต์ของคุณ และเลือกที่จะใช้ HSTS กับโดเมนย่อยที่ใช้ HTTPS การใช้วิธีนี้จะทำให้ไซต์ของคุณมีการป้องกันขั้นพื้นฐานโดยใช้ส่วนหัวความปลอดภัย HTTP แต่ข้อเสียคือ Cloudflare ไม่อนุญาตให้คุณเพิ่ม X-Frame-Options ในขณะนี้

เป็นที่น่าสังเกตว่าสำหรับ servebolt.com และโดเมนอื่นๆ ภายใน Cloudflare นั้น HSTS จะถูกเปิดใช้งานตามค่าเริ่มต้น

การเพิ่ม HTTP Security Headers โดยใช้ปลั๊กอิน WordPress

วิธีที่สามในการเพิ่มและกำหนดค่าส่วนหัว HTTP คือการใช้ปลั๊กอิน แม้ว่านี่จะเป็นหนึ่งในวิธีที่ง่ายที่สุดในการเพิ่มส่วนหัว HTTP Security ให้กับเว็บไซต์ WordPress ของคุณ แต่โดยปกติแล้วจะมีประสิทธิภาพน้อยกว่าการกำหนดค่าส่วนหัวด้วยตนเองเล็กน้อย

คุณอาจได้อ่านที่อื่นแล้วว่าปลั๊กอินความปลอดภัยจำนวนมากมีตัวเลือกในการเพิ่มส่วนหัวความปลอดภัย อย่างไรก็ตาม เราไม่แนะนำให้ใช้ปลั๊กอินความปลอดภัย อ่านบทความของเราเกี่ยวกับปลั๊กอินความปลอดภัยของ WordPress เพื่อทำความเข้าใจสาเหตุและข้อกังวลเกี่ยวกับการใช้สิ่งเหล่านี้

ส่วนนี้จะให้คุณเปิดหรือปิดใช้งานส่วนหัวต่างๆ และตั้งค่าพารามิเตอร์ต่างๆ สำหรับส่วนหัวเหล่านั้น ส่วนหัวที่คุณสามารถเปิดใช้งานได้จะแตกต่างกันไปขึ้นอยู่กับปลั๊กอินที่คุณเลือก แต่ส่วนหัวทั่วไป เช่น X-XSS-Protection, X-Content-Type-Options, X-Frame-Options และ Strict-Transport-Security จะครอบคลุมโดย ปลั๊กอินส่วนใหญ่

วิธีตรวจสอบ HTTP Security Headers บนเว็บไซต์ของคุณ

หลังจากเพิ่มส่วนหัวการรักษาความปลอดภัย HTTP บนเว็บไซต์ WordPress ของคุณแล้ว คุณต้องแน่ใจว่ามีการกำหนดค่าอย่างถูกต้องและทำงานตามที่คาดไว้ คุณสามารถใช้เครื่องมือฟรีที่มีอยู่มากมายบนอินเทอร์เน็ตเพื่อทำการทดสอบ เราขอแนะนำ ให้ใช้ Security Headers หรือ SSL Labs ซึ่งทั้งสองวิธีจะช่วยให้คุณทดสอบการกำหนดค่าและตรวจสอบว่าส่วนหัวด้านความปลอดภัยทั้งหมดทำงานได้อย่างถูกต้อง

เครื่องมือเหล่านี้จะประเมินส่วนหัวด้านความปลอดภัยของเว็บไซต์ของคุณและให้รายงานโดยละเอียดแก่คุณ พวกเขายังแจ้งให้คุณทราบว่าเว็บไซต์ของคุณกำลังส่งส่วนหัวความปลอดภัย HTTP ใดและไม่ได้ส่งส่วนหัวใด จากนั้นไซต์ของคุณจะได้รับคะแนนจาก A+ ถึง F พร้อมด้วยคำอธิบายว่ากำหนดเกรดนั้นอย่างไร

ตัวอย่างเช่น เมื่อทดสอบ เว็บไซต์ของ Vogue เราพบว่าไม่มีส่วนหัว HTTP ที่สำคัญหลายรายการ ดังนั้นจึงได้รับเพียงเกรด C

และอย่างที่คุณคาดไว้เมื่อทดสอบเว็บไซต์ของเรา – เว็บนี้ได้รับเกรด A+

บทสรุป

ไม่ต้องสงสัยเลยว่าการใช้ส่วนหัว HTTP เป็นขั้นตอนสำคัญในการรักษาความปลอดภัยให้เว็บไซต์ของคุณ หลังจากเพิ่มส่วนหัว HTTP ลงในเว็บไซต์ของคุณเรียบร้อยแล้ว ต่อไปนี้คือขั้นตอนเพิ่มเติมบางส่วนที่คุณควรพิจารณาด้วย:

1. ทดสอบช่องโหว่ : สิ่งสำคัญคือต้องทดสอบไซต์ของคุณเพื่อหาช่องโหว่ด้านความปลอดภัยทั่วไป เช่น Cross-Site-Scripting (CSS) และ Cross-site-request-Forgery (CSRF)เพื่อจุดประสงค์ นี้ คุณสามารถใช้เครื่องมือต่างๆ เช่น OWASP ZAP และ Burp Suite
2. ตรวจสอบการเปลี่ยนแปลง : คุณต้องตรวจสอบส่วนหัวเป็นประจำเพื่อหาการเปลี่ยนแปลงที่ไม่คาดคิด เนื่องจากมักจะบ่งชี้ว่ามีความพยายามใช้ประโยชน์จากช่องโหว่
3. อัปเดตส่วนหัว : เมื่อมีภัยคุกคามใหม่ๆ เกิดขึ้น สิ่งสำคัญคือต้องติดตามแนวทางปฏิบัติด้านความปลอดภัยล่าสุดอยู่เสมอและอัปเดตส่วนหัวของคุณตามนั้น

สนใจโฮสติ้งที่ได้รับการจัดการซึ่งเร็วกว่าอย่างเห็นได้ชัดหรือไม่?

ลองใช้วิธีการโฮสติ้ง WordPress ของเรา – เริ่มต้นใช้งานได้ฟรี และสิทธิประโยชน์ต่างๆ ได้แก่:

• ความสามารถในการปรับขนาด: ในการทดสอบเวิร์กโหลดของผู้ใช้จริง Servebolt ให้เวลาตอบสนองเฉลี่ยที่ 65 มิลลิวินาที ซึ่งเร็วกว่าเวลาตอบสนองอันดับสองถึง 4.9 เท่า
• เวลาในการโหลดทั่วโลกเร็วที่สุด: เวลาในการโหลดหน้าเว็บเฉลี่ย 1.26 วินาที ทำให้เราอยู่ในอันดับต้น ๆ ของรายการผลการทดสอบ WebPageTest ทั่วโลก
• ความเร็วในการประมวลผลที่เร็วที่สุด: เซิร์ฟเวอร์ Servebolt ให้ความเร็วฐานข้อมูลที่ไม่เคยได้ยินมาก่อน ประมวลผลข้อความค้นหาต่อวินาทีมากกว่าค่าเฉลี่ย 2.44 เท่า และเรียกใช้ PHP เร็วกว่าอันดับสองที่ดีที่สุด 2.6 เท่า!
• ความปลอดภัยและเวลาทำงานที่สมบูรณ์แบบ: ด้วยเวลาทำงาน 100% บนจอภาพทั้งหมดและคะแนน A+ จากการใช้งาน SSL ของเรา คุณจึงมั่นใจได้ว่าไซต์ของคุณออนไลน์และปลอดภัย

กล่าวโดยสรุปก็คือ การปล่อยให้เราจัดการโฮสต์นอกจานของคุณ – คุณจะทำให้การปรับปรุงความปลอดภัย ความเร็ว และประสิทธิภาพของไซต์ของคุณง่ายขึ้น ลงทะเบียนสำหรับ Servebolt เพื่อทดสอบเรา