ดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัวที่ช่วยให้เว็บไซต์ปลอดภัยและค้นหารายละเอียดที่สำคัญที่สุดได้อย่างรวดเร็ว
บทความนี้จะแสดงส่วนหัวความปลอดภัยที่สำคัญที่สุดที่คุณใช้ปกป้องเว็บไซต์ได้ ใช้ข้อมูลนี้เพื่อทําความเข้าใจฟีเจอร์ความปลอดภัยบนเว็บ ดูวิธีติดตั้งใช้งานในเว็บไซต์ และใช้เป็นข้อมูลอ้างอิงเมื่อคุณต้องการการช่วยเตือน
- ส่วนหัวความปลอดภัยที่แนะนำสำหรับเว็บไซต์ที่จัดการข้อมูลที่ละเอียดอ่อนของผู้ใช้
- นโยบายรักษาความปลอดภัยเนื้อหา (CSP)
- ประเภทที่เชื่อถือได้
- ส่วนหัวความปลอดภัยที่แนะนำสำหรับเว็บไซต์ทั้งหมด
- X-Content-Type-Options
- X-Frame-Options
- นโยบายทรัพยากรข้ามต้นทาง (CORP)
- นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (COOP)
- ความปลอดภัยที่เข้มงวดในการรับส่งข้อมูลแบบ HTTP (HSTS)
- ส่วนหัวความปลอดภัยสำหรับเว็บไซต์ที่มีความสามารถขั้นสูง มีดังนี้
- กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS)
- นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP)
ก่อนเจาะลึกไปที่ส่วนหัวความปลอดภัย ให้ดูข้อมูลเกี่ยวกับภัยคุกคามที่รู้จักบนเว็บและเหตุผลที่ควรใช้ส่วนหัวความปลอดภัยเหล่านี้
ปกป้องเว็บไซต์จากช่องโหว่ในการแทรก
ช่องโหว่ในการแทรกเกิดขึ้นเมื่อข้อมูลที่ไม่น่าเชื่อถือซึ่งประมวลผลโดยแอปพลิเคชันอาจส่งผลต่อลักษณะการทำงาน และมักนำไปสู่การดำเนินการของสคริปต์ที่ผู้โจมตีควบคุม ช่องโหว่ที่พบบ่อยที่สุดที่เกิดจากข้อบกพร่องในการแทรกคือ cross-site Scripting (XSS) ในรูปแบบต่างๆ รวมถึง XSS ที่สะท้อนกลับ, XSS ที่จัดเก็บไว้, XSS ที่ใช้ DOM และตัวแปรอื่นๆ
โดยทั่วไปแล้ว ช่องโหว่ XSS อาจทำให้ผู้โจมตีเข้าถึงข้อมูลผู้ใช้ที่แอปพลิเคชันประมวลผล รวมทั้งข้อมูลอื่นๆ ที่โฮสต์ในต้นทางเว็บเดียวกันได้อย่างเต็มรูปแบบ
การป้องกันการแทรกแบบเดิมจะรวมถึงการใช้ระบบเทมเพลต HTML โดยอัตโนมัติแบบหลบเลี่ยง การหลีกเลี่ยงการใช้ JavaScript API ที่เป็นอันตราย และการประมวลผลข้อมูลผู้ใช้อย่างเหมาะสมโดยการโฮสต์การอัปโหลดไฟล์ไว้ในโดเมนแยกต่างหากและทำความสะอาด HTML ที่ผู้ใช้ควบคุมเอง
- ใช้นโยบายรักษาความปลอดภัยเนื้อหา (CSP) เพื่อควบคุมสคริปต์ที่จะเรียกใช้โดยแอปพลิเคชันเพื่อลดความเสี่ยงของการแทรก
- ใช้ประเภทที่เชื่อถือได้เพื่อบังคับใช้การทำความสะอาดข้อมูลที่ส่งผ่านไปยัง JavaScript API ที่เป็นอันตราย
- ใช้ X-Content-Type-Options เพื่อป้องกันไม่ให้เบราว์เซอร์ตีความประเภท MIME ของทรัพยากรในเว็บไซต์ผิดพลาด ซึ่งอาจนำไปสู่การดำเนินการสคริปต์
แยกเว็บไซต์ของคุณจากเว็บไซต์อื่น
ความเปิดกว้างของเว็บทำให้เว็บไซต์ต่างๆ สามารถโต้ตอบระหว่างกันในลักษณะที่อาจละเมิดความคาดหวังด้านความปลอดภัยของแอปพลิเคชัน ซึ่งรวมถึงการสร้างคำขอที่ตรวจสอบสิทธิ์แล้วโดยไม่คาดคิด หรือการฝังข้อมูลจากแอปพลิเคชันอื่นในเอกสารของผู้โจมตี ทำให้ผู้โจมตีแก้ไขหรืออ่านข้อมูลแอปพลิเคชันได้
ช่องโหว่ทั่วไปที่บ่อนทำลายการแยกเว็บไซต์ ได้แก่ การหลอกให้คลิก, การปลอมแปลงคำขอแบบข้ามเว็บไซต์ (CSRF), การรวมสคริปต์ข้ามเว็บไซต์ (XSSI) และการรั่วไหลข้ามเว็บไซต์ต่างๆ
- ใช้ X-Frame-Options เพื่อป้องกันไม่ให้เว็บไซต์ที่เป็นอันตรายฝังเอกสาร
- ใช้นโยบายทรัพยากรข้ามต้นทาง (CORP) เพื่อป้องกันไม่ให้เว็บไซต์แบบข้ามต้นทางรวมทรัพยากรของเว็บไซต์
- ใช้นโยบายเปิดแบบข้ามต้นทาง (COOP) เพื่อปกป้องหน้าต่างของเว็บไซต์จากการโต้ตอบจากเว็บไซต์ที่เป็นอันตราย
- ใช้กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS) เพื่อควบคุมการเข้าถึงทรัพยากรของเว็บไซต์จากเอกสารแบบข้ามต้นทาง
การพัฒนาเว็บแบบ Post-Spectre เป็นบทความที่ดีหากคุณสนใจส่วนหัวเหล่านี้
สร้างเว็บไซต์ที่มีประสิทธิภาพอย่างปลอดภัย
Spectre วางข้อมูลที่โหลดลงในกลุ่มบริบทการท่องเว็บเดียวกันซึ่งอาจอ่านได้แม้จะมีนโยบายต้นทางเดียวกัน เบราว์เซอร์จะจำกัดฟีเจอร์ที่อาจใช้ประโยชน์จากช่องโหว่เบื้องหลังสภาพแวดล้อมพิเศษที่เรียกว่า "การแยกแบบข้ามต้นทาง" การแยกแบบข้ามต้นทางช่วยให้คุณใช้ฟีเจอร์ที่มีประสิทธิภาพ เช่น SharedArrayBuffer ได้
- ใช้นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP) ร่วมกับ COOP เพื่อเปิดใช้การแยกแบบข้ามต้นทาง
เข้ารหัสการเข้าชมเว็บไซต์ของคุณ
ปัญหาการเข้ารหัสจะปรากฏขึ้นเมื่อแอปพลิเคชันไม่ได้เข้ารหัสข้อมูลที่อยู่ระหว่างการส่งโดยสมบูรณ์ ซึ่งทำให้ผู้โจมตีที่แอบดูข้อมูลการโต้ตอบของผู้ใช้กับแอปพลิเคชันได้
การเข้ารหัสไม่เพียงพออาจเกิดขึ้นในกรณีต่อไปนี้: ไม่ใช้ HTTPS, เนื้อหาผสม, การตั้งค่าคุกกี้โดยไม่มีแอตทริบิวต์ Secure
(หรือ __Secure
นำหน้า) หรือลดตรรกะการตรวจสอบ CORS
- ใช้ความปลอดภัยที่เข้มงวดในการรับส่งข้อมูลแบบ HTTP (HSTS) เพื่อแสดงเนื้อหาผ่าน HTTPS
นโยบายรักษาความปลอดภัยเนื้อหา (CSP)
cross-Site Scripting (XSS) เป็นการโจมตีที่ช่องโหว่บนเว็บไซต์ทำให้สคริปต์ที่เป็นอันตรายถูกแทรกและดำเนินการได้
Content-Security-Policy จะเพิ่มชั้นเพื่อลดการโจมตี XSS โดยการจำกัดสคริปต์ที่หน้าเว็บเรียกใช้ได้
เราขอแนะนำให้คุณเปิดใช้ CSP ที่เข้มงวดโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
- หากคุณแสดงผลหน้า HTML บนเซิร์ฟเวอร์ ให้ใช้ CSP ที่เข้มงวดแบบ nonce
- หาก HTML ต้องแสดงแบบคงที่หรือแคช เช่น หากเป็นแอปพลิเคชันหน้าเว็บเดียว ให้ใช้ CSP ที่เข้มงวดตามแฮช
ตัวอย่างการใช้งาน: CSP แบบ nonce
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
การใช้งานที่แนะนำ
1. ใช้ CSP ที่เข้มงวดที่อิงตาม nonce {: #nonce-based-csp}
หากคุณแสดงผลหน้า HTML บนเซิร์ฟเวอร์ ให้ใช้ CSP ที่เข้มงวดแบบ nonce
สร้างค่า Nonce ใหม่ของสคริปต์สำหรับทุกคำขอในฝั่งเซิร์ฟเวอร์และตั้งค่าส่วนหัวต่อไปนี้
ไฟล์การกำหนดค่าเซิร์ฟเวอร์
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
ใน HTML หากต้องการโหลดสคริปต์ ให้ตั้งค่าแอตทริบิวต์ nonce ของแท็ก <script> ทั้งหมดเป็นสตริง {RANDOM1} เดียวกัน
index.html
<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
// Inline scripts can be used with the <code>nonce</code> attribute.
</script>
Google Photos เป็นตัวอย่าง CSP ที่เข้มงวดตามแบบ Nonce ใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูลักษณะการใช้งาน
2. ใช้ CSP ที่เข้มงวดตามแฮช {: #hash-based-csp}
หาก HTML ต้องแสดงแบบคงที่หรือแคช เช่น หากคุณกำลังสร้างแอปพลิเคชันหน้าเว็บเดียว ให้ใช้ CSP ที่เข้มงวดตามแฮช
ไฟล์การกำหนดค่าเซิร์ฟเวอร์
Content-Security-Policy:
script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
ใน HTML คุณจะต้องแทรกสคริปต์ในหน้าเพื่อใช้นโยบายตามแฮช เนื่องจากเบราว์เซอร์ส่วนใหญ่ไม่รองรับการแฮชสคริปต์ภายนอก
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
หากต้องการโหลดสคริปต์ภายนอก โปรดอ่าน "โหลดสคริปต์ที่มาจากแบบไดนามิก" ในส่วนตัวเลือก B: ส่วนหัวการตอบกลับ CSP แบบแฮช
CSP Evaluator เป็นเครื่องมือที่ดีในการประเมิน CSP แต่ขณะเดียวกันก็ถือเป็นตัวอย่าง CSP ที่เข้มงวดตามแบบ nonce ด้วย ใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูลักษณะการใช้งาน
เบราว์เซอร์ที่รองรับ
สิ่งอื่นๆ ที่ควรทราบเกี่ยวกับ CSP
- คำสั่ง
frame-ancestorsปกป้องเว็บไซต์จากการหลอกให้คลิก ซึ่งเป็นความเสี่ยงที่เกิดขึ้นหากคุณอนุญาตให้เว็บไซต์ที่ไม่น่าเชื่อถือฝังเว็บไซต์ของคุณได้ หากต้องการใช้โซลูชันที่ง่ายกว่า คุณสามารถใช้X-Frame-Optionsเพื่อบล็อกการโหลด แต่frame-ancestorsจะกำหนดค่าขั้นสูงเพื่ออนุญาตให้เฉพาะต้นทางบางรายการเป็นผู้ฝัง - คุณอาจใช้ CSP เพื่อให้มั่นใจว่าทรัพยากรทั้งหมดของเว็บไซต์โหลดผ่าน HTTPS กลายเป็นเรื่องที่เกี่ยวข้องน้อยลง ปัจจุบันเบราว์เซอร์ส่วนใหญ่บล็อกเนื้อหาผสม
- นอกจากนี้ คุณยังตั้งค่า CSP ในโหมดรายงานเท่านั้นได้ด้วย
- หากตั้งค่า CSP เป็นฝั่งเซิร์ฟเวอร์ส่วนหัวไม่ได้ คุณจะตั้งค่าเป็นเมตาแท็กได้เช่นกัน โปรดทราบว่าคุณใช้โหมดรายงานเท่านั้นกับเมตาแท็กไม่ได้ (แต่อาจมีการเปลี่ยนแปลง)
ดูข้อมูลเพิ่มเติม
ประเภทที่เชื่อถือได้
XSS แบบ DOM คือการโจมตีที่มีการส่งข้อมูลที่เป็นอันตรายไปยังซิงก์ที่รองรับการดำเนินการกับโค้ดแบบไดนามิก เช่น eval() หรือ .innerHTML
Trusted Types มีเครื่องมือในการเขียน การตรวจสอบความปลอดภัย และดูแลรักษาแอปพลิเคชันโดยไม่มี DOM XSS โดยสามารถเปิดใช้ผ่าน CSP และทำให้โค้ด JavaScript ปลอดภัยโดยค่าเริ่มต้นด้วยการจำกัด API ของเว็บที่เป็นอันตรายให้ยอมรับเฉพาะออบเจ็กต์พิเศษประเภท Trusted Type เท่านั้น
หากต้องการสร้างออบเจ็กต์เหล่านี้ คุณจะกำหนดนโยบายความปลอดภัยได้เพื่อให้แน่ใจว่ามีการใช้กฎความปลอดภัย (เช่น การหลบเลี่ยงหรือการทำความสะอาดข้อมูล) อย่างสอดคล้องกันก่อนที่จะเขียนข้อมูลไปยัง DOM นโยบายเหล่านี้เป็นเพียงที่เดียวในโค้ด ที่อาจแนะนำ DOM XSS ได้
ตัวอย่างการใช้งาน
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
การใช้งานที่แนะนำ
-
บังคับใช้ Trusted Types สำหรับซิงก์ DOM ที่เป็นอันตราย ส่วนหัว CSP และ Trusted Types:
Content-Security-Policy: require-trusted-types-for 'script'
ปัจจุบัน
'script'เป็นค่าเดียวที่ยอมรับได้สำหรับคำสั่งrequire-trusted-types-forแน่นอนว่า คุณสามารถใช้ Trusted Types กับคำสั่งของ CSP อื่นๆ ได้ ดังนี้
การผสาน CSP ที่อิงตาม Noce จากด้านบนกับประเภทที่เชื่อถือได้
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>หมายเหตุ: </b> คุณสามารถจำกัดชื่อนโยบาย Trusted Types ที่อนุญาตได้โดยการตั้งค่าคำสั่ง <code>trusted-types</code> เพิ่มเติม (เช่น <code>trusted-types myPolicy</code>) อย่างไรก็ตาม นี่ไม่ใช่ข้อกำหนด </aside>
-
กำหนดนโยบาย
นโยบาย:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
ใช้นโยบาย
ใช้นโยบายเมื่อเขียนข้อมูลไปยัง DOM
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
เมื่อใช้ require-trusted-types-for 'script' การใช้ประเภทที่เชื่อถือได้เป็นข้อกำหนด การใช้ DOM API ที่เป็นอันตรายกับสตริงจะทำให้เกิดข้อผิดพลาด
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
- ป้องกันช่องโหว่ในการเขียนสคริปต์ข้ามเว็บไซต์ตาม DOM ด้วยประเภทที่เชื่อถือได้
- CSP: required-trusted-types-for - HTTP |
MDN
- CSP: ประเภทที่เชื่อถือได้ - HTTP | MDN
- การสาธิตประเภท Trusted - เปิดเครื่องมือตรวจสอบเครื่องมือสำหรับนักพัฒนาเว็บและดูว่าเกิดอะไรขึ้น
X-Content-Type-Options
เมื่อมีการแสดงเอกสาร HTML ที่เป็นอันตรายจากโดเมนของคุณ (เช่น หากรูปภาพที่อัปโหลดไปยังบริการรูปภาพมีมาร์กอัป HTML ที่ถูกต้อง) บางเบราว์เซอร์จะถือว่าเอกสารดังกล่าวเป็นเอกสารที่ใช้งานอยู่และอนุญาตให้เรียกใช้สคริปต์ในบริบทของแอปพลิเคชัน ซึ่งนำไปสู่ข้อบกพร่องของการเขียนสคริปต์ข้ามเว็บไซต์
X-Content-Type-Options: nosniff จะป้องกันได้ด้วยคำสั่งเบราว์เซอร์ว่าประเภท MIME ที่ตั้งไว้ในส่วนหัวของ Content-Type สำหรับการตอบสนองที่กำหนดถูกต้อง เราแนะนำให้ใช้ส่วนหัวนี้สำหรับทรัพยากรทั้งหมด
ตัวอย่างการใช้งาน
X-Content-Type-Options: nosniff
การใช้งานที่แนะนำ
เราขอแนะนำให้ใช้ X-Content-Type-Options: nosniff สำหรับทรัพยากรทั้งหมดที่ให้บริการจากเซิร์ฟเวอร์ของคุณพร้อมกับส่วนหัว Content-Type ที่ถูกต้อง
ตัวอย่างส่วนหัวที่ส่งด้วย HTML ของเอกสาร
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
ตัวเลือก X-Frame
หากเว็บไซต์ที่เป็นอันตรายสามารถฝังเว็บไซต์ของคุณเป็น iframe ได้ อาจทำให้ผู้โจมตีเรียกใช้การดำเนินการโดยไม่ได้ตั้งใจจากผู้ใช้ด้วย clickjacking ได้ นอกจากนี้ ในบางกรณี การโจมตีแบบสเปคเตอร์ทำให้เว็บไซต์ที่เป็นอันตรายมีโอกาสเรียนรู้เกี่ยวกับเนื้อหาของเอกสารที่ฝัง
X-Frame-Options จะระบุว่าควรอนุญาตให้เบราว์เซอร์แสดงผลหน้าใน <frame>, <iframe>, <embed> หรือ <object> หรือไม่ เอกสารทั้งหมด เราขอแนะนำให้ส่งส่วนหัวนี้เพื่อระบุว่าจะอนุญาตให้เอกสารอื่นๆ ฝังไว้หรือไม่
ตัวอย่างการใช้งาน
X-Frame-Options: DENY
การใช้งานที่แนะนำ
เอกสารทั้งหมดที่ไม่ได้ออกแบบมาให้ฝังควรใช้ส่วนหัว X-Frame-Options
คุณลองใช้วิธีที่การกำหนดค่าต่อไปนี้ส่งผลต่อการโหลด iframe ได้ในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลง X-Frame-Options แล้วคลิกปุ่มโหลด iframe ซ้ำ
ปกป้องเว็บไซต์ของคุณไม่ให้ถูกฝังโดยเว็บไซต์อื่นๆ
ปฏิเสธไม่ให้เอกสารอื่นฝังตัว
X-Frame-Options: DENY
ปกป้องเว็บไซต์ของคุณไม่ให้ถูกฝังโดยเว็บไซต์ข้ามต้นทาง
อนุญาตให้ฝังโดยเอกสารต้นทางเดียวกันเท่านั้น
X-Frame-Options: SAMEORIGIN
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายทรัพยากรข้ามโดเมน (CORP)
ผู้โจมตีอาจฝังทรัพยากรจากต้นทางอื่น เช่น จากเว็บไซต์ เพื่อดูข้อมูลเกี่ยวกับแหล่งที่มาดังกล่าวโดยใช้ประโยชน์จากการรั่วไหลข้ามเว็บไซต์บนเว็บ
Cross-Origin-Resource-Policy จะลดความเสี่ยงนี้ได้ด้วยการระบุชุดของเว็บไซต์ที่โหลดได้ ส่วนหัวจะใช้ค่าใดค่าหนึ่งจาก 3 ค่า ได้แก่ same-origin, same-site และ cross-origin ขอแนะนำให้ทรัพยากรทั้งหมดส่งส่วนหัวนี้เพื่อระบุว่าจะอนุญาตให้เว็บไซต์อื่นๆ โหลดได้หรือไม่
ตัวอย่างการใช้งาน
Cross-Origin-Resource-Policy: same-origin
การใช้งานที่แนะนำ
ขอแนะนำให้ใช้ทรัพยากรทั้งหมดด้วยส่วนหัว 1 ใน 3 รายการต่อไปนี้
คุณสามารถลองว่าการกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรภายใต้สภาพแวดล้อม Cross-Origin-Embedder-Policy: require-corp อย่างไรในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลง Cross-Origin-Resource-Policy แล้วคลิกปุ่มโหลด
iframe ซ้ำ หรือCross-Origin-Resource-Policyเพื่อดูเอฟเฟกต์
อนุญาตให้โหลดทรัพยากร cross-origin
เราขอแนะนำให้บริการที่คล้ายกับ CDN ใช้ cross-origin กับทรัพยากร (เนื่องจากมักจะโหลดโดยหน้าแบบข้ามต้นทาง) เว้นแต่จะแสดงผ่าน CORS ซึ่งให้ผลที่คล้ายกันอยู่แล้ว
Cross-Origin-Resource-Policy: cross-origin
จำกัดทรัพยากรที่จะโหลดจาก same-origin
ควรใช้ same-origin กับทรัพยากรที่มีไว้เพื่อโหลดโดยหน้าต้นทางเดียวกันเท่านั้น คุณควรใช้นโยบายนี้กับทรัพยากรที่มีข้อมูลที่ละเอียดอ่อนเกี่ยวกับผู้ใช้ หรือคำตอบของ API ที่มีวัตถุประสงค์ให้เรียกใช้จากต้นทางเดียวกันเท่านั้น
โปรดทราบว่าทรัพยากรที่มีส่วนหัวนี้จะยังโหลดได้โดยตรง เช่น การไปที่ URL ในหน้าต่างเบราว์เซอร์ใหม่ นโยบายทรัพยากรแบบข้ามต้นทาง ปกป้องเฉพาะทรัพยากรไม่ให้ถูกฝังโดยเว็บไซต์อื่นเท่านั้น
Cross-Origin-Resource-Policy: same-origin
จำกัดทรัพยากรที่จะโหลดจาก same-site
ขอแนะนําให้ใช้ same-site กับทรัพยากรที่คล้ายกับข้างต้น แต่มีไว้เพื่อโหลดโดยโดเมนย่อยอื่นๆ ของเว็บไซต์
Cross-Origin-Resource-Policy: same-site
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (COOP)
เว็บไซต์ของผู้โจมตีอาจเปิดเว็บไซต์อื่นในหน้าต่างป๊อปอัปเพื่อดูข้อมูลเกี่ยวกับเว็บไซต์ดังกล่าวโดยใช้ประโยชน์จากการรั่วไหลข้ามเว็บไซต์บนเว็บ ในบางกรณี การทำเช่นนี้อาจทำให้มีการแสวงหาประโยชน์จากการโจมตีแบบ Side-Channel ที่อิงจาก Spectre
ส่วนหัว Cross-Origin-Opener-Policy ช่วยให้เอกสารแยกตัวเองออกจากหน้าต่างแบบข้ามต้นทางที่เปิดผ่าน window.open() หรือลิงก์ที่มี target="_blank" ที่ไม่มี rel="noopener" ด้วยเหตุนี้ โปรแกรมเปิดแบบข้ามต้นทางของเอกสารจึงจะไม่มีการอ้างอิงเอกสารนั้น และจะไม่สามารถโต้ตอบกับเอกสารได้
ตัวอย่างการใช้งาน
Cross-Origin-Opener-Policy: same-origin-allow-popups
การใช้งานที่แนะนำ
คุณลองใช้การกำหนดค่าต่อไปนี้มีผลต่อการสื่อสารด้วยหน้าต่างป๊อปอัปข้ามต้นทางได้ในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลง Cross-Origin-Opener-Policy สำหรับทั้งเอกสารและหน้าต่างป๊อปอัป คลิกปุ่มCross-Origin-Opener-Policy จากนั้นคลิกส่ง postMessage เพื่อดูว่าระบบส่งข้อความจริงหรือไม่
แยกเอกสารออกจากหน้าต่างแบบข้ามต้นทาง
การตั้งค่า same-origin จะทำให้เอกสารถูกแยกออกจากหน้าต่างเอกสารแบบข้ามต้นทาง
Cross-Origin-Opener-Policy: same-origin
แยกเอกสารจากหน้าต่างแบบข้ามต้นทาง แต่อนุญาตให้มีป๊อปอัป
การตั้งค่า same-origin-allow-popups ช่วยให้เอกสารเก็บการอ้างอิงไปยังหน้าต่างป๊อปอัปได้ เว้นแต่จะตั้งค่า COOP ด้วย same-origin หรือ same-origin-allow-popups ซึ่งหมายความว่า same-origin-allow-popups จะยังคงปกป้องเอกสารไม่ให้มีการอ้างอิงเมื่อเปิดเป็นหน้าต่างป๊อปอัปได้ แต่อนุญาตให้สื่อสารกับป๊อปอัปของตนเอง
Cross-Origin-Opener-Policy: same-origin-allow-popups
อนุญาตให้หน้าต่างแบบข้ามต้นทางอ้างอิงเอกสาร
unsafe-none เป็นค่าเริ่มต้น แต่คุณระบุอย่างชัดเจนว่าเอกสารนี้จะเปิดเอกสารนี้ได้ด้วยหน้าต่างแบบข้ามต้นทางและยังคงรักษาสิทธิ์เข้าถึงร่วมกันได้
Cross-Origin-Opener-Policy: unsafe-none
รูปแบบรายงานใช้ร่วมกับ COOP ไม่ได้
คุณจะได้รับรายงานเมื่อ COOP ป้องกันการโต้ตอบข้ามหน้าต่างกับ Reporting API
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP ยังรองรับโหมดรายงานเท่านั้นเพื่อให้คุณรับรายงานได้โดยไม่ต้องบล็อกการสื่อสารระหว่างเอกสารแบบข้ามต้นทางจริงๆ
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS)
กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS) ต่างจากรายการอื่นๆ ในบทความนี้คือส่วนหัว แต่เป็นกลไกของเบราว์เซอร์ที่ขอและอนุญาตการเข้าถึงทรัพยากรแบบข้ามต้นทาง
โดยค่าเริ่มต้น เบราว์เซอร์จะบังคับใช้นโยบายต้นทางเดียวกันเพื่อป้องกันไม่ให้หน้าเว็บเข้าถึงทรัพยากรแบบข้ามต้นทาง เช่น เมื่อโหลดรูปภาพข้ามต้นทางแล้ว แม้ว่าจะแสดงในหน้าเว็บเป็นภาพ แต่ JavaScript ในหน้าเว็บไม่มีสิทธิ์เข้าถึงข้อมูลของรูปภาพ ผู้ให้บริการทรัพยากรสามารถผ่อนปรนข้อจำกัดและอนุญาตให้เว็บไซต์อื่นๆ อ่านแหล่งข้อมูลได้โดยเลือกเข้าร่วมกับ CORS
ตัวอย่างการใช้งาน
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
ก่อนดูวิธีกำหนดค่า CORS คุณควรเข้าใจความแตกต่างของคำขอประเภทต่างๆ ระบบจะจัดประเภทคำขอเป็นคำขอแบบง่ายหรือคำขอที่ได้รับการตรวจสอบล่วงหน้า ทั้งนี้ขึ้นอยู่กับรายละเอียดของคำขอ
เกณฑ์สำหรับคำของ่ายๆ มีดังนี้
- เมธอดคือ
GET,HEADหรือPOST - ส่วนหัวที่กำหนดเองจะมีเฉพาะ
Accept,Accept-Language,Content-LanguageและContent-Typeเท่านั้น Content-Typeคือapplication/x-www-form-urlencoded,multipart/form-dataหรือtext/plain
สิ่งอื่นๆ ทั้งหมดจัดเป็นคำขอที่มีการตรวจสอบล่วงหน้า ดูรายละเอียดเพิ่มเติมได้ที่การแชร์ทรัพยากรข้ามต้นทาง (CORS) - HTTP | MDN
การใช้งานที่แนะนำ
คำขอแบบง่าย
เมื่อคำขอตรงตามเกณฑ์คำขอแบบง่าย เบราว์เซอร์จะส่งคำขอข้ามต้นทางที่มีส่วนหัว Origin ซึ่งระบุต้นทางที่ส่งคำขอ
ตัวอย่างส่วนหัวของคำขอ
Get / HTTP/1.1 Origin: https://example.com
ตัวอย่างส่วนหัวการตอบกลับ
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.comบ่งบอกว่าhttps://example.comเข้าถึงเนื้อหาคำตอบได้ ทรัพยากรที่จะอนุญาตให้อ่านได้โดยเว็บไซต์ใดก็ตามจะตั้งค่าส่วนหัวนี้เป็น*ได้ ซึ่งในกรณีนี้เบราว์เซอร์จะกำหนดให้ส่งคำขอโดยไม่มีข้อมูลเข้าสู่ระบบเพียงอย่างเดียวAccess-Control-Allow-Credentials: trueระบุว่าคำขอที่มีข้อมูลเข้าสู่ระบบ (คุกกี้) ได้รับอนุญาตให้โหลดทรัพยากร มิเช่นนั้น คำขอที่ตรวจสอบสิทธิ์แล้วจะถูกปฏิเสธแม้ว่าจะมีต้นทางที่ขออยู่ในส่วนหัวAccess-Control-Allow-Originก็ตาม
คุณลองดูว่าคำขอแบบง่ายส่งผลต่อการโหลดทรัพยากรภายใต้สภาพแวดล้อม Cross-Origin-Embedder-Policy: require-corp ได้ในการสาธิตนี้อย่างไร คลิกช่องทำเครื่องหมายการแชร์ทรัพยากรข้ามต้นทาง แล้วคลิกปุ่มโหลดรูปภาพซ้ำเพื่อดูเอฟเฟกต์
คำขอที่ได้รับการตรวจสอบล่วงหน้า
ระบบจะดำเนินการกับคำขอที่กำหนดไว้ล่วงหน้าก่อนคำขอ OPTIONS เพื่อตรวจสอบว่าระบบอนุญาตให้ส่งคำขอหลังจากนั้นหรือไม่
ตัวอย่างส่วนหัวของคำขอ
OPTIONS / HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method: POSTอนุญาตให้ส่งคำขอต่อไปนี้ด้วยเมธอดPOSTAccess-Control-Request-Headers: X-PINGOTHER, Content-Typeอนุญาตให้ผู้ขอตั้งค่าส่วนหัว HTTP ของX-PINGOTHERและContent-Typeในคำขอที่ตามมา
ตัวอย่างส่วนหัวการตอบกลับ
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: POST, GET, OPTIONSบ่งบอกว่าสามารถส่งคำขอต่อๆ ไปได้โดยใช้เมธอดPOST,GETและOPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-Typeบ่งบอกว่าคำขอในลำดับต่อๆ มาใส่ส่วนหัวX-PINGOTHERและContent-Typeได้Access-Control-Max-Age: 86400บ่งบอกว่าสามารถแคชผลลัพธ์ของคำขอที่ได้รับการตรวจสอบล่วงหน้าเป็นเวลา 86,400 วินาที
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP)
เพื่อลดความสามารถในการขโมยทรัพยากรแบบข้ามต้นทางของการโจมตีแบบสเปกเตอร์ ฟีเจอร์ต่างๆ เช่น SharedArrayBuffer หรือ performance.measureUserAgentSpecificMemory() จะถูกปิดใช้โดยค่าเริ่มต้น
Cross-Origin-Embedder-Policy: require-corp ป้องกันไม่ให้เอกสารและผู้ปฏิบัติงานโหลดทรัพยากรแบบข้ามต้นทาง เช่น รูปภาพ, สคริปต์, สไตล์ชีต, iframe และอื่นๆ เว้นแต่ว่าทรัพยากรเหล่านี้จะเลือกโหลดผ่านส่วนหัว CORS หรือ CORP อย่างชัดแจ้ง คุณรวม COEP กับ Cross-Origin-Opener-Policy ได้เพื่อเลือกให้เอกสารใช้การแยกแบบข้ามต้นทาง
ใช้ Cross-Origin-Embedder-Policy: require-corp เมื่อคุณต้องการเปิดใช้การแยกแบบข้ามต้นทางสำหรับเอกสาร
ตัวอย่างการใช้งาน
Cross-Origin-Embedder-Policy: require-corp
ตัวอย่างการใช้งาน
COEP มีค่าเดียวเป็น require-corp การส่งส่วนหัวนี้จะทำให้คุณสั่งให้เบราว์เซอร์บล็อกทรัพยากรการโหลดที่ไม่ได้เลือกใช้ผ่าน CORS หรือ CORP ได้
คุณลองใช้การกำหนดค่าต่อไปนี้มีผลต่อการโหลดทรัพยากรได้ในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลงCross-Origin-Embedder-Policy, เมนูแบบเลื่อนลงCross-Origin-Embedder-Policy, ช่องทำเครื่องหมายCross-Origin-Embedder-Policy เป็นต้น เพื่อดูว่าการเปลี่ยนแปลงเหล่านี้ส่งผลต่อการโหลดทรัพยากรอย่างไร จากนั้นเปิดการสาธิตปลายทางการรายงานเพื่อดูว่ามีการรายงานทรัพยากรที่ถูกบล็อกหรือไม่
เปิดใช้การแยกแบบข้ามต้นทาง
เปิดใช้การแยกแบบข้ามต้นทางโดยการส่ง Cross-Origin-Embedder-Policy: require-corp ไปพร้อมกับ Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin
รายงานทรัพยากรที่ไม่สามารถใช้ร่วมกับ COEP
คุณจะได้รับรายงานของทรัพยากรที่ถูกบล็อกซึ่งเกิดจาก COEP ได้ด้วย Reporting API
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
นอกจากนี้ COEP ยังรองรับโหมดรายงานเท่านั้นเพื่อให้คุณรับรายงานได้โดยไม่ต้องบล็อกทรัพยากรในการโหลด
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
การรักษาความปลอดภัยที่เข้มงวดในการรับส่งข้อมูลแบบ HTTP (HSTS)
การสื่อสารผ่านการเชื่อมต่อ HTTP แบบธรรมดาจะไม่มีการเข้ารหัส จึงทำให้ผู้สอดแนมระดับเครือข่ายเข้าถึงข้อมูลที่โอนได้
ส่วนหัว Strict-Transport-Security จะบอกเบราว์เซอร์ว่าไม่ควรโหลดเว็บไซต์โดยใช้ HTTP และใช้ HTTPS แทน เมื่อตั้งค่าแล้ว เบราว์เซอร์จะใช้ HTTPS แทน HTTP เพื่อเข้าถึงโดเมนโดยไม่มีการเปลี่ยนเส้นทางตามระยะเวลาที่กำหนดไว้ในส่วนหัว
ตัวอย่างการใช้งาน
Strict-Transport-Security: max-age=31536000
การใช้งานที่แนะนำ
เว็บไซต์ทั้งหมดที่เปลี่ยนจาก HTTP เป็น HTTPS ควรตอบกลับด้วยส่วนหัว Strict-Transport-Security เมื่อได้รับคำขอที่มี HTTP
Strict-Transport-Security: max-age=31536000
เบราว์เซอร์ที่รองรับ