หัวข้อ Permissions-Policy สามารถล็อกสิ่งใดได้จริง

สรุปสั้น ๆ

Permissions-Policy คือ HTTP response header ที่ช่วยให้ไซต์จำกัดการเข้าถึงฟีเจอร์บางอย่างของเบราว์เซอร์ได้ เช่น กล้อง ไมโครโฟน ตำแหน่งทางภูมิศาสตร์ fullscreen การชำระเงิน เซ็นเซอร์ และ API ย่อยอีกจำนวนมาก

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

เรื่องนี้สำคัญเพราะเว็บไซต์สมัยใหม่ถูกประกอบขึ้นจาก snippet วิเคราะห์ข้อมูล, media embeds, chat widgets, consent managers, สคริปต์โฆษณา, แผนที่, payment flows และการทดลองภายใน องค์ประกอบส่วนใหญ่เหล่านั้นไม่จำเป็นต้องเข้าถึง device APIs ที่ทรงพลัง นโยบายที่ดีทำให้เรื่องนี้ชัดเจน

หากคุณกำลังตรวจสอบ headers ใน production อยู่แล้ว ให้ทำงานนี้ควบคู่กับการตรวจ response จริงโดยตรง คู่มือของเราเกี่ยวกับ การ debug redirects และ HTTP headers ใน production ครอบคลุมนิสัยสำคัญในเรื่องนี้: ตรวจดูสิ่งที่เบราว์เซอร์ได้รับจริง ไม่ใช่สิ่งที่ไฟล์ configuration ของคุณบอกว่าควรเกิดขึ้น

Permissions-Policy ควบคุมอะไร

Header นี้ควบคุมการเข้าถึงฟีเจอร์ของเบราว์เซอร์ที่ระบุชื่อไว้ รายการที่แน่นอนเปลี่ยนแปลงไปตามเวลาเพราะ browser APIs เปลี่ยนแปลง แต่ directive ที่พบบ่อยรวมถึง:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort ในการอภิปรายรุ่นเก่า ปัจจุบันส่วนใหญ่เป็นเรื่องเชิงประวัติศาสตร์แล้ว

Directive หนึ่งรายการสามารถอนุญาตฟีเจอร์สำหรับไม่มีใครเลย สำหรับ origin ปัจจุบัน หรือสำหรับ origin ที่เลือกไว้ ตัวอย่างเช่น:

Permissions-Policy: camera=(), microphone=(), geolocation=(self)

หมายความว่ากล้องและไมโครโฟนถูกปิดใช้งานสำหรับ document และ nested browsing contexts ของมัน ขณะที่ geolocation อนุญาตเฉพาะ origin เดียวกันเท่านั้น

ตัวอย่างที่ผ่อนปรนมากขึ้น:

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

ตัวอย่างนี้อนุญาตให้ origin ของคุณเองและผู้ให้บริการแผนที่ที่ระบุชื่อหนึ่งรายใช้ geolocation ได้ และอนุญาตให้ origin ของคุณเองรวมถึงผู้ให้บริการวิดีโอรายหนึ่งร้องขอ fullscreen ได้

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

สิ่งที่ล็อกได้บนเพจของคุณเอง

บน first-party pages, Permissions-Policy มีประโยชน์ที่สุดในฐานะราวกันตก มันลดขอบเขตผลกระทบของโค้ดที่เกิดขึ้นโดยไม่ตั้งใจหรือไม่คาดคิด

เช่น เพจการตลาดอาจไม่จำเป็นต้องใช้ไมโครโฟน กล้อง Bluetooth, USB, motion sensors หรือ payment APIs คุณสามารถปฏิเสธฟีเจอร์เหล่านั้นแบบทั่วทั้งไซต์ได้:

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

สิ่งนี้ไม่ได้ทำให้ทุกสคริปต์บนเพจน่าเชื่อถือ แต่มันหมายความว่า หาก tag manager experiment, dependency ที่ถูก compromise หรือ widget ที่วางเข้ามาพยายามเรียก restricted API เบราว์เซอร์ไม่ควรให้สิทธิ์เข้าถึง

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

นั่นคือแรงเสียดทานชนิดที่เหมาะสม

สิ่งที่ล็อกได้ใน iframe

Header นี้มีประโยชน์เป็นพิเศษเมื่อเกี่ยวข้องกับ embedded content

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

ตัวอย่างเช่น หากเพจของคุณฝัง video player, support widget และแผนที่ คุณสามารถหลีกเลี่ยงการให้ทุกเฟรมเข้าถึงทุกฟีเจอร์ได้ คุณอาจอนุญาต fullscreen เฉพาะสำหรับเฟรมวิดีโอ และอนุญาต geolocation เฉพาะสำหรับเฟรมแผนที่

มีสองชั้นที่ควรเข้าใจ:

1. HTTP Permissions-Policy header กำหนดนโยบายสำหรับ document
2. iframe allow attribute สามารถมอบสิทธิ์ฟีเจอร์เฉพาะให้เฟรมได้ แต่ต้องอยู่ภายในขอบเขตที่ parent policy อนุญาตเท่านั้น

iframe แบบง่ายอาจมีหน้าตาเช่นนี้:

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

หาก header ของคุณปฏิเสธ fullscreen ทั้งหมด iframe attribute จะไม่สามารถ override การปฏิเสธนั้นได้ หาก header ของคุณอนุญาต fullscreen สำหรับ origin นั้น iframe attribute จึงสามารถมอบสิทธิ์ให้ได้

ลำดับชั้นนี้เป็นหนึ่งในเหตุผลที่ header นี้คุ้มค่าต่อการใช้งาน มันให้วิธีแก่ทีม platform หรือ security ในการกำหนดขอบเขตทั่วทั้งไซต์ ขณะที่ยังเปิดให้ทีม product เปิดใช้งาน embeds เฉพาะจุดเมื่อจำเป็น

สิ่งที่ล็อกไม่ได้

นี่คือจุดที่บางทีมประเมิน header นี้สูงเกินไป

Permissions-Policy ไม่ได้แทนที่ content security policy มันไม่ได้ตัดสินว่าสคริปต์ใดโหลดได้ มันไม่หยุดสคริปต์จากการส่งข้อมูลผ่านเครือข่าย มันไม่ sanitize HTML มันไม่ป้องกัน XSS มันไม่บล็อก form spam หากปัญหาคือการ abuse แบบฟอร์ม ให้เริ่มจากกลไกที่อธิบายไว้ใน ทำไม contact form ของคุณจึงเป็นความเสี่ยง spam ที่ใหญ่ที่สุด ไม่ใช่จาก header นี้

มันยังไม่ได้แทนที่การกำกับดูแลคุกกี้ Cookies, local storage, consent, third-party embeds และ browser tracking protections เป็นประเด็นแยกต่างหาก หากคุณกำลังทบทวน privacy controls ในภาพรวม ภูมิทัศน์ของคุกกี้ควรถูกตรวจแยกอีกครั้ง การเปลี่ยนแปลงเชิงปฏิบัติครอบคลุมไว้ใน สิ่งที่เปลี่ยนไปสำหรับ cookies ในปี 2026 และควรทำอย่างไร

สิ่งสำคัญที่สุดคือ Permissions-Policy ไม่ได้ทำให้ JavaScript ของบุคคลที่สามเป็นส่วนตัว หากคุณโหลดสคริปต์บุคคลที่สามเข้ามาใน first-party page ของคุณ โดยทั่วไปมันจะทำงานด้วยสิทธิ์ของเพจคุณ ภายใต้ข้อจำกัดอื่นของเบราว์เซอร์และ security headers ของคุณ การปฏิเสธการเข้าถึงกล้องเป็นเรื่องดี แต่มันไม่หยุดสคริปต์นั้นจากการอ่านเนื้อหา DOM, สังเกตการกระทำของผู้ใช้ หรือทำ network requests ที่ได้รับอนุญาต

สำหรับเรื่องนั้น คุณต้องใช้การควบคุมแบบอื่น: การเลือก vendor อย่างรอบคอบ, CSP, sandboxed iframes, Subresource Integrity เมื่อใช้ได้, data minimization และการ review ที่น่าเบื่อแต่จำเป็น

นโยบายค่าเริ่มต้นที่สมเหตุสมผล

ไม่มี header สากลที่เหมาะกับทุกไซต์ แต่ไซต์เนื้อหาและการตลาดส่วนใหญ่สามารถเริ่มจากแบบเข้มงวดได้

แนวทางแรกที่สมเหตุสมผล:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

จากนั้นค่อยเพิ่มกลับเฉพาะสิ่งที่ไซต์ใช้งานจริง

ตัวอย่างเช่น:

• ร้านค้าที่ใช้ Payment Request API อาจต้องใช้ payment=(self)
• เครื่องมือค้นหาสถานที่อาจต้องใช้ geolocation=(self) หรือ origin แผนที่ที่เชื่อถือได้
• แอปประชุมออนไลน์อาจต้องใช้ camera=(self) และ microphone=(self)
• ไซต์ที่เน้นวิดีโอจำนวนมากอาจต้องใช้ fullscreen=(self "https://trusted-video.example")

ส่วนสำคัญคืออย่าคัดลอกนโยบายขนาดใหญ่จาก checklist แล้วถือว่าเสร็จ เริ่มจาก inventory ฟีเจอร์ของคุณ เพจใดต้องใช้ browser capabilities ใดบ้าง? Embed ใดต้องการ delegation? ฟีเจอร์ใดจะดูน่าประหลาดใจหากมีการร้องขอ?

วิธี deploy โดยไม่ทำให้สิ่งต่าง ๆ เสียหาย

นำสิ่งนี้ออกใช้งานเหมือน production header อื่น ๆ: อย่างตั้งใจ

1. ทำ inventory การใช้ฟีเจอร์

ค้นหาใน codebase ของคุณสำหรับการเรียก browser API เช่น getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB และ wake lock APIs

จากนั้นตรวจ third-party embeds เอกสารของผู้ให้บริการวิดีโอ แผนที่ การชำระเงิน และ identity provider มักระบุค่า iframe allow ที่จำเป็น

2. เริ่มในสภาพแวดล้อมที่มีความเสี่ยงต่ำ

เพิ่ม header แบบเข้มงวดใน staging และทดสอบเส้นทางหลักของผู้ใช้ ใส่ใจกับข้อความใน browser console เบราว์เซอร์มักรายงานเมื่อฟีเจอร์ถูกบล็อกโดย permissions policy

3. ใช้นโยบายเฉพาะเพจเมื่อจำเป็น

อย่าบังคับใช้นโยบาย global เพียงชุดเดียว หาก product ของคุณมีประเภทเพจที่แตกต่างกันมาก Blog, checkout, map page และ video room อาจต้องใช้ capability ต่างกัน

Web servers, frameworks และ edge platforms ส่วนใหญ่สามารถตั้ง headers แบบมีเงื่อนไขตาม path ได้ วิธีนี้มักสะอาดกว่าการลดความเข้มงวดของทั้งไซต์เพื่อฟีเจอร์เดียว

4. ตรวจสอบ response จริง

Headers อาจถูกเพิ่ม เขียนทับ ทำซ้ำ หรือถูกลบโดย CDNs, reverse proxies, app servers และ middleware ตรวจ response สุดท้ายใน browser DevTools หรือด้วย command-line tools

ทดสอบ embedded contexts ด้วย เพจระดับบนสุดที่ดูถูกต้องไม่ได้รับประกันว่า iframe ได้รับ delegation ตามที่คุณตั้งใจไว้

5. บันทึกข้อยกเว้น

ทุกฟีเจอร์ที่อนุญาตควรมีเจ้าของและเหตุผล เรื่องนี้ฟังดูเป็นระบบราชการ จนกระทั่งหกเดือนต่อมา เมื่อไม่มีใครจำได้ว่าเหตุใด geolocation จึงถูกเปิดให้ vendor domain ที่ไม่ปรากฏบนเพจแล้ว

ข้อผิดพลาดด้าน syntax ที่พบบ่อย

Syntax ของ header สมัยใหม่กระชับ แต่ผิดพลาดเล็กน้อยได้ง่าย

ใช้วงเล็บว่างเพื่อปฏิเสธฟีเจอร์:

Permissions-Policy: microphone=()

ใช้ self สำหรับ origin ปัจจุบัน:

Permissions-Policy: geolocation=(self)

ใช้ origin แบบใส่เครื่องหมายคำพูดสำหรับ external origins ที่เฉพาะเจาะจง:

Permissions-Policy: fullscreen=(self "https://video.example")

หลีกเลี่ยงการพึ่งพาตัวอย่าง Feature-Policy เก่า เว้นแต่ว่าคุณตั้งใจรองรับ legacy behavior Header รุ่นเก่าใช้ syntax ที่แตกต่างกัน และไม่ใช่สิ่งที่คุณควรออกแบบโดยยึดเป็นหลักในวันนี้

และจำไว้ว่าการรองรับของเบราว์เซอร์แตกต่างกันไปตาม directive เบราว์เซอร์หนึ่งอาจรองรับ header แต่ไม่รองรับ feature directive บางรายการ นั่นเป็นเรื่องปกติ ให้มอง header นี้เป็นมาตรการ defense-in-depth ไม่ใช่ privacy หรือ security control เพียงอย่างเดียวของคุณ

<!-- tool-cta:start -->

💡 ลองสิ่งนี้: ตรวจสอบว่า Permissions-Policy ของคุณถูกส่งตามที่ตั้งใจไว้ด้วย Get Headers ซึ่งแสดงส่วนหัวการตอบกลับดิบที่เซิร์ฟเวอร์ของคุณกำลังส่ง

<!-- tool-cta:end -->

คุณค่าด้าน privacy ในทางปฏิบัติ

คุณค่าด้าน privacy ของ Permissions-Policy ไม่ใช่การทำให้ไซต์นิรนามหรือปลอด tracker มันไม่ได้ทำเช่นนั้น

คุณค่าของมันคือการจำกัดการเข้าถึง browser capabilities ที่อ่อนไหว ตำแหน่ง กล้อง ไมโครโฟน device sensors, local hardware APIs และ payment flows ล้วนทรงพลัง เพจส่วนใหญ่ไม่ต้องการสิ่งเหล่านี้ องค์ประกอบที่ฝังอยู่จำนวนมากไม่ควรสามารถขอสิ่งเหล่านี้ได้เลย

นี่คือการปรับปรุงที่แท้จริง มันลด prompt ที่เกิดขึ้นโดยไม่ตั้งใจ จำกัดการเปิดเผย capability ที่ไม่จำเป็น และให้ artifact ที่เป็นรูปธรรมแก่ทีมของคุณเพื่อ review เมื่อฟังก์ชันใหม่ถูกปล่อยใช้งาน

เวอร์ชันที่ดีที่สุดของ header นี้ควรน่าเบื่อ: เข้มงวดโดยค่าเริ่มต้น ผ่อนคลายเฉพาะเมื่อฟีเจอร์ที่ผู้ใช้มองเห็นต้องการ และทดสอบเป็นส่วนหนึ่งของกระบวนการ release ปกติ