คู่มือ Permissions-Policy Generator: ควบคุม Browser Feature แยกตาม Origin

ทุกวันนี้ browser เปิด API ที่ทรงพลังให้เว็บใช้งานได้มากกว่าที่หลายคนคิด สคริปต์ใดก็ตามที่รันบนหน้าของคุณสามารถขอเข้าถึง camera, microphone, ตำแหน่งที่ตั้ง (geolocation) ไปจนถึงเรียก payment sheet ได้ ซึ่งสะดวกเมื่อเป็นโค้ดของเราเอง แต่เสี่ยงมากเมื่อมาจาก third-party tag ที่ถูกบุกรุก Permissions-Policy คือ HTTP header ที่ทำหน้าที่เป็นเส้นเขตแดนของ browser: กำหนดว่าหน้าของคุณและ iframe ที่ฝังอยู่ใช้ feature ใดได้บ้าง

ไวยากรณ์ของ header ดูง่าย แต่พอใช้จริงกลับพลาดได้ง่ายมาก วงเล็บที่หายไปหนึ่งคู่หรือ quote ที่เกินมาหนึ่งตัว อาจทำให้ feature ที่ควรใช้ได้พัง หรือเปิดช่องที่ควรปิดโดยไม่รู้ตัว Permissions-Policy Generator ช่วยตัดความคาดเดาออกไปทั้งหมด: เปิด-ปิด feature เป็นกลุ่มตามหมวด เลือกโหมด deny, self หรือ custom origin แล้วคัดลอก header พร้อม preset สำหรับ nginx, Apache และ Express ได้ทันที ทั้งหมดทำงาน 100% ในเบราว์เซอร์ของคุณ

บทความนี้จะอธิบายว่าเหตุใด header นี้จึงสำคัญ เครื่องมือทำงานอย่างไร และมี recipe พร้อมใช้สำหรับเว็บสามแบบที่ต่างกัน

ทำไมต้องใช้ Permissions-Policy Generator?

• ตัวช่วยสร้างแบบ visual แทนการอ่าน spec — เปิด-ปิด feature มากกว่า 25 รายการ ตั้งแต่ camera, microphone ไปจนถึง geolocation, payment, USB และ Bluetooth จัดกลุ่มตามหมวดให้เลือกง่าย
• ควบคุมแยกตาม origin ได้ทุก feature — เลือก deny ทั้งหมด, อนุญาตเฉพาะ origin เดียวกัน, อนุญาตทุก origin หรือระบุ allowlist เองสำหรับ embed และพาร์ทเนอร์
• Preset สำหรับงาน hardening ทั่วไป — Deny sensitive ปิด feature เสี่ยงทั้งหมดในคลิกเดียว ส่วน Self for common เปิด feature ที่ใช้บ่อยเฉพาะ origin ของคุณ
• ผลลัพธ์พร้อมใช้ 4 รูปแบบ — ค่า header ดิบ พร้อม snippet สำหรับ nginx add_header, Apache Header always set และ Express.js middleware res.setHeader
• ไม่ต้องสมัคร ฟรี และเป็นส่วนตัว — ทำงานในเบราว์เซอร์ 100% policy ของคุณไม่ถูกส่งออกไปที่ใด

ฟีเจอร์หลัก

• header preview คือความจริงสุดท้าย — สิ่งที่คุณคัดลอกคือสิ่งที่ browser จะได้รับจริง ไม่มีการแปลงต่อ
• Preset เป็นจุดเริ่มต้น ไม่ใช่คำตอบสุดท้าย — เปิดคืนเฉพาะ feature ที่โปรดักต์เรียกใช้จริง
• Custom origins ใส่ได้หลาย origin คั่นด้วย comma และเครื่องมือจะใส่ quote ให้ถูกต้องตาม spec

วิธีใช้งาน Permissions-Policy Generator

1. เปิด feature ที่ต้องการควบคุม — feature ที่ไม่เปิดจะไม่ถูกใส่ใน header ทำให้ใช้ค่า default ของ browser (เครื่องมือแสดงสถานะนี้ให้เห็นชัดเจน)
2. เลือกโหมดการอนุญาตของแต่ละ feature — Deny everywhere สำหรับสิ่งที่เว็บไม่เคยใช้, Same origin only สำหรับความสามารถที่โค้ดคุณต้องใช้
3. ใส่ custom origin เมื่อจำเป็น — สำหรับ video meeting, support widget หรือ partner checkout ให้ใส่ origin ที่ต้องการอนุญาต คั่นด้วย comma
4. ตรวจ header และ preset ที่สร้างได้ — การ์ด header แสดงสตริงสุดท้าย ส่วนการ์ด nginx, Apache และ Express แสดงวิธีนำไปใช้บน stack ของคุณ
5. คัดลอกไป deploy แล้วตรวจสอบ — วางใน config ของ server, CDN หรือ edge โหลดหน้าใหม่ แล้วเช็กว่า response มี header นี้จริง

Allow, Block และ Delegate

Permissions-Policy คือรายการ directive คั่นด้วย comma หนึ่งรายการต่อหนึ่ง feature:

Permissions-Policy: camera=(self), geolocation=(), payment=(self "https://pay.example")

• camera=(self) — อนุญาต camera เฉพาะ origin ของคุณ; iframe ข้าม origin จะไม่ได้สิทธิ์เว้นแต่ delegate ให้
• geolocation=() — allowlist ว่างหมายถึงบล็อกทุกที่ รวมทั้งหน้าของคุณเองและทุก frame ที่ฝังอยู่
• payment=(self "https://pay.example") — self บวกหนึ่ง origin ที่ระบุ พร้อม quote ตามรูปแบบ

Default กับ delegation ต่างกันอย่างไร

Permissions-Policy เป็น allowlist ไม่ใช่ blocklist: feature ที่คุณไม่พูดถึงจะใช้ค่า default ของ browser ซึ่งโดยทั่วไปคือเฉพาะ origin เดียวกัน แต่บาง feature default เป็น * คือทุก origin ใช้ได้ ดังนั้น "ไม่ได้ตั้ง header" จึงไม่เท่ากับ "บล็อกแล้ว" ทุก directive ที่ใส่จะแทนที่ default ด้วย origin ที่ระบุเท่านั้น สำหรับ iframe ข้าม origin ยังมีเงื่อนไขที่สองเพิ่มอีกชั้น: policy ของหน้าแม่ต้องมี origin ของ frame และแท็ก iframe ต้องขอ feature ผ่าน attribute allow ด้วย

ทำไมการบล็อก feature ที่ไม่ใช้จึงสำคัญ

ทุก feature ที่เปิดไว้คือความสามารถที่ผู้โจมตีจะได้ไปด้วย หาก injected script รันบนหน้าเว็บของคุณได้ การบล็อก feature ที่โปรดักต์ไม่ได้ใช้ลดพื้นที่โจมตีของ API เหล่านั้นเหลือศูนย์ และยังตัด permission prompt ที่ทำให้ผู้ใช้กด Allow โดยไม่อ่านทิ้งไปด้วย live chat ที่ไม่ต้องใช้ microphone ควรประกาศไว้ใน header แทนที่จะหวังให้ผู้ใช้ปฏิเสธเอง

Recipe 3 แบบ

เว็บ content ทั่วไปแทบไม่ต้องใช้ device API อะไรเลย จึงบล็อกชุดที่อ่อนไหวทั้งหมดไว้:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), serial=(), bluetooth=(), midi=(), hid=(), accelerometer=(), gyroscope=(), magnetometer=(), display-capture=(), idle-detection=()

แอปธนาคารควรเปิดเฉพาะสิ่งที่โปรดักต์ใช้จริงบน origin ของตัวเอง ส่วน passkey ต้องอาศัย publickey-credentials-get:

Permissions-Policy: camera=(self), microphone=(self), geolocation=(), payment=(self), usb=(), serial=(), bluetooth=(), hid=(), midi=(), accelerometer=(), gyroscope=(), magnetometer=(), idle-detection=(), publickey-credentials-get=(self)

SaaS ที่มี embed ควร delegate camera และ microphone ให้เฉพาะ origin ของบริการประชุมเท่านั้น:

Permissions-Policy: camera=(self "https://meet.example.com"), microphone=(self "https://meet.example.com"), display-capture=(self), geolocation=(self), payment=(), usb=(self), serial=(), bluetooth=()

Use Cases ในทางปฏิบัติ

เว็บ content และ marketing

เว็บ editorial ไม่ต้องใช้ device API อยู่แล้ว แต่ bundle ของ theme และ analytics อาจมีโค้ดที่เรียกขอได้ การบล็อกชุดที่อ่อนไหวจะตัด prompt เหล่านั้นออก และทำให้เรื่อง privacy อธิบายง่ายขึ้น

แอป fintech และธนาคาร

สำหรับโปรดักต์ที่อยู่ในข้อกำหนดกำกับ header นี้ช่วยเป็นหลักฐานของ least privilege ได้: บล็อก sensor และ device API ที่ไม่ได้ใช้ เปิด camera และ microphone เฉพาะ origin เดียวกันเมื่อมีขั้นตอน video KYC จริง และคง publickey-credentials-get=(self) ไว้ให้ passkey ใช้งานได้

SaaS ที่มี third-party embed

meeting widget, live chat ที่แชร์หน้าจอ และ embedded checkout ต่างต้องการความสามารถเพียงเล็กน้อยเท่านั้น การใช้ custom origin ช่วย delegate camera หรือ payment ให้พาร์ทเนอร์รายที่ระบุ ขณะที่ feature อื่นปิดไว้ทั้งหมด

Security audit และ header scanner

เครื่องสแกน header ให้คะแนน Permissions-Policy ควบกับ CSP และ HSTS และการไม่มี policy ถือเป็น finding ที่พบบ่อยใน external audit การมี policy ที่เก็บใน version control ทำให้แก้ไขเสร็จในบรรทัดเดียว

แนวทางปฏิบัติที่ดีที่สุด

• เริ่มจากเข้มที่สุด แล้วเปิดเท่าที่พัง — feature ที่ไม่เปิดไม่มีต้นทุนอะไร ส่วน feature ที่ลืมจำกัดจะเปิดให้ทุกสคริปต์บนหน้าใช้ได้เสมอ
• ทดสอบ embed ทุกครั้งหลังแก้ไข — feature ใน iframe ต้องอาศัยทั้ง header ของหน้าแม่และ attribute allow ให้ตรงกัน จึงควรทดสอบฟลว embed ซ้ำทุกครั้ง
• ส่งเป็น HTTP header เท่านั้น ไม่ใช่ meta tag — Permissions-Policy ไม่มีรูปแบบ <meta http-equiv> จึงต้องมาจาก server, CDN หรือ edge config เท่านั้น
• ออดิททุกไตรมาส — สคริปต์บุคคลที่สามเข้ามาและจากไป; feature ที่เคยเปิดให้ widget ที่เลิกใช้แล้วควรถูกถอนคืน
• เลือก self แทน * — เครื่องหมายดอกจันรวมทุก origin รวมถึง frame ที่คุณไม่ได้ควบคุม ใช้เฉพาะเมื่อต้องการอนุญาตทุก origin จริง ๆ
• เก็บ policy ไว้ใน version control — ปฏิบัติกับ header เหมือนโค้ด: รีวิวการเปลี่ยนแปลง บันทึกเหตุผลที่อนุญาตแต่ละ origin และ rollback ได้เมื่อ embed พัง

พร้อมล็อก browser feature หรือยัง? เปิด Permissions-Policy Generator เลือก feature ที่เว็บของคุณใช้จริง แล้วคัดลอก header พร้อม preset nginx, Apache และ Express ได้ในไม่ถึงนาที

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Security Headers Generator — สร้างชุด security header ที่แนะนำทั้งหมดในครั้งเดียว
• CSP Generator — ควบคุมว่า script, style และ frame ใดโหลดได้บ้าง
• HSTS Header Generator — บังคับ HTTPS และป้องกันการโจมตีแบบ protocol downgrade

ดูแลความปลอดภัยของเว็บคุณอยู่เสมอ!

คำถามที่พบบ่อย

ถ: Permissions-Policy ต่างจาก Feature-Policy อย่างไร?

ตอบ: Feature-Policy คือชื่อเดิมของ header นี้ และบทเรียนเก่าหลายแห่งยังใช้ไวยากรณ์แบบเก่าอยู่ Permissions-Policy คือมาตรฐานใหม่ที่ใช้รูปแบบต่างออกไป เช่น camera=(self) แทน camera 'self' และ browser สมัยใหม่รองรับเฉพาะชื่อใหม่เท่านั้น

ถ: Permissions-Policy แทนที่ permission prompt ของผู้ใช้หรือไม่?

ตอบ: ไม่ — header เป็นเพียงเพดานสูงสุด ผู้ใช้ยังต้องกดอนุญาตสำหรับ camera, microphone และ geolocation อยู่ดี แต่ feature ที่ถูก header บล็อกจะใช้ไม่ได้เลยและไม่มีการแสดง prompt ด้วย

ถ: ตั้ง Permissions-Policy ผ่าน meta tag ได้ไหม?

ตอบ: ไม่ได้ — ต่างจาก Content-Security-Policy ตรงที่ Permissions-Policy ไม่มีรูปแบบ meta tag ต้องส่งเป็น HTTP response header จาก server, CDN หรือ edge platform เท่านั้น

ถ: การบล็อก camera จะทำให้เว็บพังหรือไม่?

ตอบ: พังเฉพาะกรณีที่มีโค้ดใช้งาน feature นั้นจริง ๆ ให้ตรวจโค้ดของตัวเองและทุก iframe แล้วบล็อกส่วนที่เหลือ โดยปกติมีแค่ video conference กับฟลวอัปโหลดผ่านกล้องที่ต้องใช้ camera จริง