เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์: การใช้งาน Content Security Policy (CSP) อย่างเชี่ยวชาญ

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

เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์คืออะไร?

เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์คือ HTTP response headers ที่เว็บเซิร์ฟเวอร์ส่งไปยังเบราว์เซอร์ เฮดเดอร์เหล่านี้มีคำแนะนำเกี่ยวกับวิธีที่เบราว์เซอร์ควรจัดการกับเนื้อหาที่ได้รับ ซึ่งช่วยป้องกันการโจมตีทั่วไป เช่น:

• Cross-Site Scripting (XSS): การแทรกสคริปต์ที่เป็นอันตรายเข้าไปในเว็บไซต์ที่เชื่อถือได้
• Clickjacking: การหลอกลวงให้ผู้ใช้คลิกสิ่งที่แตกต่างจากที่พวกเขารับรู้
• Man-in-the-Middle Attacks: การดักจับการสื่อสารระหว่างผู้ใช้และเซิร์ฟเวอร์

เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์ที่สำคัญที่สุดบางส่วน ได้แก่:

• Content Security Policy (CSP): กำหนดแหล่งที่มาที่เบราว์เซอร์ได้รับอนุญาตให้โหลดทรัพยากร
• Strict-Transport-Security (HSTS): บังคับให้เบราว์เซอร์ใช้ HTTPS สำหรับการสื่อสารทั้งหมดกับเว็บไซต์
• X-Frame-Options: ป้องกันไม่ให้เว็บไซต์ถูกฝังใน iframe เพื่อลดการโจมตีแบบ clickjacking
• X-XSS-Protection: เปิดใช้งานตัวกรอง XSS ในตัวของเบราว์เซอร์ (หมายเหตุ: มักถูกแทนที่ด้วย CSP แต่ยังสามารถให้การป้องกันอีกชั้นหนึ่งได้)
• Referrer-Policy: ควบคุมปริมาณข้อมูล referrer ที่ส่งไปพร้อมกับคำขอ
• Feature-Policy (ปัจจุบันคือ Permissions-Policy): อนุญาตให้นักพัฒนาเลือกเปิดและปิดใช้งานฟีเจอร์และ API ของเบราว์เซอร์ได้

เจาะลึก Content Security Policy (CSP)

Content Security Policy (CSP) คือ HTTP response header ที่ควบคุมทรัพยากรที่ user agent ได้รับอนุญาตให้โหลดสำหรับหน้าเว็บนั้นๆ โดยพื้นฐานแล้วจะเป็นการทำ whitelist ให้กับแหล่งที่มาของเนื้อหาที่ได้รับอนุมัติ ซึ่งช่วยลดความเสี่ยงของการโจมตีแบบ XSS ได้อย่างมาก ด้วยการกำหนดแหล่งที่มาที่สามารถโหลดทรัพยากรต่างๆ เช่น สคริปต์, สไตล์ชีต, รูปภาพ และฟอนต์ได้อย่างชัดเจน CSP ทำให้ผู้โจมตีแทรกโค้ดที่เป็นอันตรายเข้ามาในเว็บไซต์ของคุณได้ยากขึ้นมาก

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

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

คำสั่ง (Directives) ของ CSP

คำสั่ง (directives) ของ CSP เป็นองค์ประกอบหลักของนโยบาย CSP ซึ่งระบุแหล่งที่มาที่อนุญาตสำหรับทรัพยากรประเภทต่างๆ คำสั่งที่ใช้กันบ่อยที่สุดบางส่วน ได้แก่:

• default-src: กำหนดแหล่งที่มาเริ่มต้นสำหรับทรัพยากรทุกประเภท นี่เป็นคำสั่งสำรองที่จะนำมาใช้เมื่อไม่มีการกำหนดคำสั่งที่เฉพาะเจาะจงกว่า
• script-src: ระบุแหล่งที่มาที่อนุญาตสำหรับ JavaScript
• style-src: ระบุแหล่งที่มาที่อนุญาตสำหรับ CSS stylesheets
• img-src: ระบุแหล่งที่มาที่อนุญาตสำหรับรูปภาพ
• font-src: ระบุแหล่งที่มาที่อนุญาตสำหรับฟอนต์
• media-src: ระบุแหล่งที่มาที่อนุญาตสำหรับเสียงและวิดีโอ
• object-src: ระบุแหล่งที่มาที่อนุญาตสำหรับปลั๊กอินเช่น Flash (โดยทั่วไปควรหลีกเลี่ยงการอนุญาตปลั๊กอินถ้าเป็นไปได้)
• frame-src: ระบุแหล่งที่มาที่อนุญาตสำหรับเฟรม (iframes)
• connect-src: ระบุแหล่งที่มาที่อนุญาตสำหรับคำขอเครือข่าย (AJAX, WebSockets)
• base-uri: จำกัด URL ที่สามารถใช้ในองค์ประกอบ <base> ได้
• form-action: จำกัด URL ที่ฟอร์มสามารถส่งข้อมูลไปได้
• frame-ancestors: ระบุ parents ที่ถูกต้องที่อาจฝังหน้าเว็บโดยใช้ <frame>, <iframe>, <object>, <embed>, หรือ <applet> คำสั่งนี้ให้การป้องกัน Clickjacking
• upgrade-insecure-requests: สั่งให้ user agents จัดการกับ URL ที่ไม่ปลอดภัยทั้งหมดของไซต์ (โหลดผ่าน HTTP) ราวกับว่าถูกแทนที่ด้วย URL ที่ปลอดภัย (โหลดผ่าน HTTPS) คำสั่งนี้มีไว้สำหรับเว็บไซต์ที่กำลังอยู่ในกระบวนการย้ายจาก HTTP ไปยัง HTTPS
• report-uri: ระบุ URL ที่เบราว์เซอร์ควรส่งรายงานเกี่ยวกับการละเมิด CSP ไปให้ เลิกใช้งานแล้วและแนะนำให้ใช้ `report-to` แทน
• report-to: ระบุชื่อกลุ่มที่กำหนดในเฮดเดอร์ `Report-To` ซึ่งช่วยให้สามารถควบคุมการรายงานได้ละเอียดมากขึ้น รวมถึงการระบุปลายทางการรายงานหลายแห่ง

ค่าแหล่งที่มา (Source Values) ของ CSP

ค่าแหล่งที่มา (Source values) กำหนดต้นทางที่อนุญาตให้โหลดทรัพยากรได้ ค่าแหล่งที่มาทั่วไปบางส่วน ได้แก่:

• *: อนุญาตเนื้อหาจากทุกแหล่งที่มา (ควรหลีกเลี่ยงการใช้งานในระดับโปรดักชัน!)
• 'self': อนุญาตเนื้อหาจากต้นทางเดียวกัน (scheme, host, และ port) กับเอกสารที่ถูกป้องกัน
• 'none': ไม่อนุญาตเนื้อหาจากแหล่งที่มาใดๆ
• 'unsafe-inline': อนุญาตให้ใช้ JavaScript และ CSS แบบอินไลน์ (ควรหลีกเลี่ยงการใช้งานในระดับโปรดักชัน!)
• 'unsafe-eval': อนุญาตให้ใช้การประเมินโค้ดแบบไดนามิก (เช่น eval(), Function()) (ควรหลีกเลี่ยงการใช้งานในระดับโปรดักชัน!)
• 'strict-dynamic': ระบุว่าความน่าเชื่อถือที่มอบให้กับสคริปต์ใน markup อย่างชัดเจนโดยมี nonce หรือ hash กำกับอยู่ จะถูกส่งต่อไปยังสคริปต์ทั้งหมดที่โหลดโดย ancestor นั้น
• 'unsafe-hashes': อนุญาต inline event handlers ที่เฉพาะเจาะจง โดยทั่วไปไม่แนะนำให้ใช้เนื่องจากความซับซ้อนและประโยชน์ที่จำกัด
• data:: อนุญาตให้โหลดทรัพยากรจาก data URLs (เช่น รูปภาพที่ฝังไว้) ควรใช้ด้วยความระมัดระวัง
• mediastream:: อนุญาตให้ใช้ `mediastream:` URIs เป็นแหล่งที่มาของสื่อ
• blob:: อนุญาตให้ใช้ `blob:` URIs เป็นแหล่งที่มาของสื่อ
• filesystem:: อนุญาตให้โหลดทรัพยากรจากระบบไฟล์
• https://example.com: อนุญาตเนื้อหาจากโดเมนและพอร์ตที่ระบุ
• *.example.com: อนุญาตเนื้อหาจากซับโดเมนใดๆ ของ example.com
• nonce-{random-value}: อนุญาตสคริปต์หรือสไตล์ที่มีแอตทริบิวต์ nonce ที่ตรงกัน ซึ่งต้องการการสร้างค่า nonce แบบสุ่มฝั่งเซิร์ฟเวอร์สำหรับแต่ละคำขอ
• sha256-{hash-value}: อนุญาตสคริปต์หรือสไตล์ที่มีค่าแฮช SHA256, SHA384 หรือ SHA512 ที่ตรงกัน

โหมดของ CSP: Enforce กับ Report-Only

CSP สามารถปรับใช้ได้สองโหมด:

• Enforce Mode: ในโหมดนี้ เบราว์เซอร์จะบล็อกทรัพยากรใดๆ ที่ละเมิด CSP นี่เป็นโหมดที่แนะนำสำหรับสภาพแวดล้อมโปรดักชัน CSP จะถูกส่งโดยใช้เฮดเดอร์ `Content-Security-Policy`
• Report-Only Mode: ในโหมดนี้ เบราว์เซอร์จะรายงานการละเมิด CSP แต่จะไม่บล็อกทรัพยากร ซึ่งมีประโยชน์สำหรับการทดสอบและประเมิน CSP ก่อนที่จะบังคับใช้ CSP จะถูกส่งโดยใช้เฮดเดอร์ `Content-Security-Policy-Report-Only`

การนำ CSP ไปใช้งาน: คู่มือทีละขั้นตอน

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

1. เริ่มต้นด้วยนโยบายแบบ Report-Only

เริ่มต้นด้วยการปรับใช้ CSP ในโหมด report-only ซึ่งช่วยให้คุณสามารถตรวจสอบการละเมิดได้โดยไม่กระทบต่อการทำงานของเว็บไซต์ของคุณ กำหนดค่าคำสั่ง report-uri หรือ report-to เพื่อส่งรายงานการละเมิดไปยังปลายทางที่กำหนด

ตัวอย่างเฮดเดอร์ (Report-Only): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. วิเคราะห์รายงานการละเมิด

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

รายงานการละเมิดมักจะถูกส่งเป็น JSON payloads ไปยังปลายทางที่กำหนดค่าไว้ใน report-uri หรือ report-to รายงานเหล่านี้มีข้อมูลเกี่ยวกับการละเมิด เช่น URI ที่ถูกบล็อก, คำสั่งที่ถูกละเมิด และ URI ของเอกสาร

3. ปรับปรุงนโยบาย CSP

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

4. เปลี่ยนไปใช้โหมด Enforce

เมื่อคุณมั่นใจว่านโยบาย CSP ของคุณไม่ได้บล็อกทรัพยากรที่ถูกต้องตามกฎหมายแล้ว ให้เปลี่ยนไปใช้โหมด enforce ซึ่งจะบล็อกการละเมิดที่เหลืออยู่และให้การป้องกันที่แข็งแกร่งต่อการโจมตีแบบ XSS

ตัวอย่างเฮดเดอร์ (Enforce): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. ตรวจสอบและบำรุงรักษานโยบาย CSP

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

ตัวอย่าง CSP ที่ใช้งานได้จริง

มาดูตัวอย่าง CSP ที่ใช้งานได้จริงสำหรับสถานการณ์ต่างๆ กัน:

ตัวอย่างที่ 1: CSP พื้นฐานสำหรับเว็บไซต์อย่างง่าย

CSP นี้อนุญาตเนื้อหาจากต้นทางเดียวกันและอนุญาตรูปภาพจากทุกแหล่งที่มา

Content-Security-Policy: default-src 'self'; img-src *

ตัวอย่างที่ 2: CSP ที่มีแหล่งที่มาของสคริปต์และสไตล์ที่เฉพาะเจาะจง

CSP นี้อนุญาตสคริปต์จากต้นทางเดียวกันและจาก CDN ที่ระบุ และสไตล์จากต้นทางเดียวกันและสไตล์แบบอินไลน์

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

ตัวอย่างที่ 3: CSP ที่มี Nonces สำหรับสคริปต์แบบอินไลน์

CSP นี้ต้องการ nonce ที่ไม่ซ้ำกันสำหรับแต่ละสคริปต์แบบอินไลน์

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

สำคัญ: ค่า nonce ต้องถูกสร้างขึ้นแบบไดนามิกบนเซิร์ฟเวอร์สำหรับแต่ละคำขอ เพื่อป้องกันไม่ให้ผู้โจมตีนำ nonce ไปใช้ซ้ำ

ตัวอย่างที่ 4: CSP ที่จำกัด Frame Ancestors เพื่อป้องกัน Clickjacking

CSP นี้ป้องกันไม่ให้หน้าเว็บถูกฝังใน iframe บนโดเมนใดๆ ยกเว้น `https://example.com`

Content-Security-Policy: frame-ancestors 'self' https://example.com

ตัวอย่างที่ 5: CSP ที่เข้มงวดมากขึ้นโดยใช้ 'strict-dynamic' และมี 'self' เป็น fallback

CSP นี้ใช้ประโยชน์จาก `strict-dynamic` สำหรับเบราว์เซอร์สมัยใหม่ในขณะที่ยังคงสนับสนุนเบราว์เซอร์รุ่นเก่าที่ไม่รองรับ นอกจากนี้ยังมี `report-uri` สำหรับการตรวจสอบการละเมิดด้วย

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

อย่าลืมแทนที่ `{random-nonce}` ด้วยค่า nonce ที่สร้างขึ้นแบบไดนามิกฝั่งเซิร์ฟเวอร์

CSP และ Single-Page Applications (SPAs)

การนำ CSP ไปใช้ใน SPAs อาจเป็นเรื่องท้าทายเนื่องจากลักษณะไดนามิกของแอปพลิเคชันเหล่านี้ SPAs มักจะพึ่งพา JavaScript อย่างมากในการสร้างและจัดการ DOM ซึ่งอาจนำไปสู่การละเมิด CSP หากไม่ได้รับการจัดการอย่างระมัดระวัง

ต่อไปนี้เป็นเคล็ดลับบางประการสำหรับการนำ CSP ไปใช้ใน SPAs:

• หลีกเลี่ยง 'unsafe-inline' และ 'unsafe-eval': ควรหลีกเลี่ยงคำสั่งเหล่านี้ทุกครั้งที่เป็นไปได้ใน SPAs เพราะมันทำให้ความปลอดภัยของแอปพลิเคชันของคุณอ่อนแอลงอย่างมาก
• ใช้ Nonces หรือ Hashes: ใช้ nonces หรือ hashes สำหรับสคริปต์และสไตล์แบบอินไลน์ นี่เป็นแนวทางที่แนะนำสำหรับ SPAs
• พิจารณา Trusted Types: Trusted Types เป็น API ของเบราว์เซอร์ที่ช่วยป้องกันช่องโหว่ DOM-based XSS สามารถใช้ร่วมกับ CSP เพื่อเพิ่มความปลอดภัยให้ดียิ่งขึ้น
• ใช้เฟรมเวิร์กที่เข้ากันได้กับ CSP: เฟรมเวิร์กฟรอนต์เอนด์บางตัว (เช่น React ที่มีการกำหนดค่าเฉพาะ, Angular และ Vue.js) มีคุณสมบัติที่ช่วยให้คุณนำ CSP ไปใช้งานได้ง่ายขึ้น

เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์ที่สำคัญอื่นๆ

แม้ว่า CSP จะเป็นรากฐานสำคัญของความปลอดภัยฝั่งฟรอนต์เอนด์ แต่เฮดเดอร์อื่นๆ ก็มีบทบาทสำคัญในการสร้างกลยุทธ์การป้องกันที่ครอบคลุม:

Strict-Transport-Security (HSTS)

เฮดเดอร์ Strict-Transport-Security (HSTS) สั่งให้เบราว์เซอร์ใช้ HTTPS เสมอในการเชื่อมต่อกับเว็บไซต์ ซึ่งช่วยป้องกันการโจมตีแบบ man-in-the-middle ที่พยายามลดระดับการเชื่อมต่อเป็น HTTP

ตัวอย่างเฮดเดอร์: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: ระบุระยะเวลา (เป็นวินาที) ที่เบราว์เซอร์ควรจดจำว่าจะเข้าถึงไซต์ผ่าน HTTPS เท่านั้น แนะนำให้ใช้ค่า 31536000 วินาที (1 ปี) สำหรับสภาพแวดล้อมโปรดักชัน
• includeSubDomains: ระบุว่านโยบาย HSTS มีผลกับซับโดเมนทั้งหมดของโดเมน
• preload: อนุญาตให้โดเมนถูกรวมอยู่ในรายชื่อโดเมนที่เปิดใช้งาน HSTS ซึ่งถูกโหลดล่วงหน้าในเบราว์เซอร์ ซึ่งต้องมีการส่งโดเมนของคุณไปยังรายการ preload HSTS ที่ดูแลโดย Google

X-Frame-Options

เฮดเดอร์ X-Frame-Options ป้องกันการโจมตีแบบ clickjacking โดยควบคุมว่าเว็บไซต์สามารถถูกฝังใน iframe ได้หรือไม่

ตัวอย่างเฮดเดอร์: X-Frame-Options: DENY

ค่าที่เป็นไปได้:

• DENY: ป้องกันไม่ให้หน้าเว็บแสดงใน iframe ไม่ว่าจะมาจากต้นทางใด
• SAMEORIGIN: อนุญาตให้หน้าเว็บแสดงใน iframe ได้ก็ต่อเมื่อต้นทางของ iframe ตรงกับต้นทางของหน้าเว็บ
• ALLOW-FROM uri: อนุญาตให้หน้าเว็บแสดงใน iframe ได้ก็ต่อเมื่อต้นทางของ iframe ตรงกับ URI ที่ระบุ หมายเหตุ: ตัวเลือกนี้เลิกใช้งานแล้วและอาจไม่ได้รับการสนับสนุนจากเบราว์เซอร์ทั้งหมด

หมายเหตุ: คำสั่ง frame-ancestors ใน CSP เป็นวิธีที่ยืดหยุ่นและมีประสิทธิภาพมากกว่าในการควบคุมการทำเฟรม และโดยทั่วไปมักเป็นที่นิยมมากกว่า X-Frame-Options

X-XSS-Protection

เฮดเดอร์ X-XSS-Protection เปิดใช้งานตัวกรอง XSS ในตัวของเบราว์เซอร์ แม้ว่า CSP จะเป็นโซลูชันที่แข็งแกร่งกว่าในการป้องกันการโจมตีแบบ XSS แต่เฮดเดอร์นี้สามารถให้การป้องกันเพิ่มเติมอีกชั้นหนึ่งได้ โดยเฉพาะสำหรับเบราว์เซอร์รุ่นเก่าที่อาจไม่รองรับ CSP อย่างเต็มที่

ตัวอย่างเฮดเดอร์: X-XSS-Protection: 1; mode=block

• 1: เปิดใช้งานตัวกรอง XSS
• 0: ปิดใช้งานตัวกรอง XSS
• mode=block: สั่งให้เบราว์เซอร์บล็อกหน้าเว็บหากตรวจพบการโจมตีแบบ XSS
• report=uri: ระบุ URL ที่เบราว์เซอร์ควรส่งรายงานไปให้หากตรวจพบการโจมตีแบบ XSS

Referrer-Policy

เฮดเดอร์ Referrer-Policy ควบคุมปริมาณข้อมูล referrer ที่ส่งไปพร้อมกับคำขอ ข้อมูล referrer สามารถใช้เพื่อติดตามผู้ใช้ข้ามเว็บไซต์ได้ ดังนั้นการควบคุมจึงสามารถปรับปรุงความเป็นส่วนตัวของผู้ใช้ได้

ตัวอย่างเฮดเดอร์: Referrer-Policy: strict-origin-when-cross-origin

ค่าที่พบบ่อยบางส่วน:

• no-referrer: ไม่ส่งเฮดเดอร์ Referer เลย
• no-referrer-when-downgrade: ไม่ส่งเฮดเดอร์ Referer ไปยังต้นทางที่ไม่มี TLS (HTTPS)
• origin: ส่งเฉพาะต้นทาง (scheme, host และ port) ในเฮดเดอร์ Referer
• origin-when-cross-origin: ส่งต้นทางสำหรับคำขอข้ามต้นทาง และ URL เต็มสำหรับคำขอจากต้นทางเดียวกัน
• same-origin: ส่งเฮดเดอร์ Referer สำหรับคำขอจากต้นทางเดียวกัน แต่ไม่ส่งสำหรับคำขอข้ามต้นทาง
• strict-origin: ส่งเฉพาะต้นทางเมื่อระดับความปลอดภัยของโปรโตคอลยังคงเท่าเดิม (HTTPS ไปยัง HTTPS) แต่ไม่ส่งเฮดเดอร์ไปยังปลายทางที่มีความปลอดภัยน้อยกว่า (HTTPS ไปยัง HTTP)
• strict-origin-when-cross-origin: ส่งต้นทางเมื่อทำคำขอจากต้นทางเดียวกัน สำหรับคำขอข้ามต้นทาง ให้ส่งต้นทางเฉพาะเมื่อระดับความปลอดภัยของโปรโตคอลยังคงเท่าเดิม (HTTPS ไปยัง HTTPS) แต่ไม่ส่งเฮดเดอร์ไปยังปลายทางที่มีความปลอดภัยน้อยกว่า (HTTPS ไปยัง HTTP)
• unsafe-url: ส่ง URL เต็มในเฮดเดอร์ Referer โดยไม่คำนึงถึงต้นทาง ควรใช้ด้วยความระมัดระวังอย่างยิ่ง เนื่องจากอาจเปิดเผยข้อมูลที่ละเอียดอ่อนได้

Permissions-Policy (เดิมคือ Feature-Policy)

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

ตัวอย่างเฮดเดอร์: Permissions-Policy: geolocation=()

ตัวอย่างนี้จะปิดใช้งาน API ตำแหน่งทางภูมิศาสตร์สำหรับเว็บไซต์

ฟีเจอร์อื่นๆ ที่สามารถควบคุมได้ด้วย Permissions-Policy ได้แก่:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

การตั้งค่าเฮดเดอร์ความปลอดภัยบนแพลตฟอร์มต่างๆ

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

Apache

คุณสามารถตั้งค่าเฮดเดอร์ความปลอดภัยใน Apache ได้โดยการเพิ่มลงในไฟล์ .htaccess หรือไฟล์กำหนดค่าเซิร์ฟเวอร์ (httpd.conf)

ตัวอย่างการกำหนดค่าใน .htaccess:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

คุณสามารถตั้งค่าเฮดเดอร์ความปลอดภัยใน Nginx ได้โดยการเพิ่มลงในบล็อกเซิร์ฟเวอร์ในไฟล์กำหนดค่า Nginx (nginx.conf)

ตัวอย่างการกำหนดค่า Nginx:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

คุณสามารถตั้งค่าเฮดเดอร์ความปลอดภัยใน Node.js ได้โดยใช้มิดเดิลแวร์อย่าง Helmet

ตัวอย่างการใช้ Helmet:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Customize CSP if needed
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare อนุญาตให้คุณตั้งค่าเฮดเดอร์ความปลอดภัยโดยใช้ Page Rules หรือ Transform Rules

การทดสอบเฮดเดอร์ความปลอดภัยของคุณ

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

• SecurityHeaders.com: เครื่องมือที่ง่ายและมีประสิทธิภาพสำหรับการวิเคราะห์เฮดเดอร์ความปลอดภัย
• Mozilla Observatory: เครื่องมือที่ครอบคลุมสำหรับการทดสอบความปลอดภัยของเว็บไซต์ รวมถึงเฮดเดอร์ความปลอดภัย
• WebPageTest.org: ช่วยให้คุณสามารถดู HTTP headers ในแผนภูมิ waterfall ได้

สรุป

เฮดเดอร์ความปลอดภัยฝั่งฟรอนต์เอนด์ โดยเฉพาะอย่างยิ่ง Content Security Policy (CSP) มีความสำคัญอย่างยิ่งต่อการปกป้องเว็บแอปพลิเคชันจากการโจมตีต่างๆ และเพิ่มความปลอดภัยของผู้ใช้ ด้วยการนำเฮดเดอร์เหล่านี้ไปใช้อย่างระมัดระวังและบำรุงรักษาอย่างต่อเนื่อง คุณจะสามารถลดความเสี่ยงของ XSS, clickjacking และช่องโหว่ด้านความปลอดภัยอื่นๆ ได้อย่างมาก อย่าลืมเริ่มต้นด้วยนโยบายแบบ report-only วิเคราะห์รายงานการละเมิด ปรับปรุงนโยบาย แล้วจึงเปลี่ยนไปใช้โหมด enforce ตรวจสอบและอัปเดตเฮดเดอร์ความปลอดภัยของคุณอย่างสม่ำเสมอเพื่อให้เว็บไซต์ของคุณปลอดภัยอยู่เสมอเมื่อมีการพัฒนาและมีภัยคุกคามใหม่ๆ เกิดขึ้น

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