Permissions-Policy header वास्तव में किन चीज़ों को लॉक डाउन कर सकता है

संक्षिप्त संस्करण

Permissions-Policy एक HTTP response header है जो किसी site को कुछ browser features तक access सीमित करने देता है: camera, microphone, geolocation, fullscreen, payment, sensors, और छोटी APIs की एक लंबी सूची।

यह कोई सामान्य privacy shield नहीं है। यह सभी tracking को नहीं रोकेगा, cookies block नहीं करेगा, network requests को नहीं रोकेगा, या third-party JavaScript को safe नहीं बनाएगा। यह जो काम अच्छी तरह कर सकता है वह सीमित है, फिर भी मूल्यवान है: आपके अपने pages और embedded frames के लिए उपलब्ध browser capabilities को कम करना।

यह इसलिए मायने रखता है क्योंकि आधुनिक websites analytics snippets, media embeds, chat widgets, consent managers, advertising scripts, maps, payment flows, और internal experiments से मिलकर बनती हैं। इनमें से अधिकांश components को powerful device APIs तक access की आवश्यकता नहीं होती। एक अच्छी policy इसे स्पष्ट कर देती है।

यदि आप पहले से production में headers review कर रहे हैं, तो इस काम को actual response की सीधी जाँच के साथ जोड़ें। production में redirects और HTTP headers debug करने पर हमारी guide यहाँ महत्वपूर्ण आदत बताती है: browser वास्तव में क्या प्राप्त करता है, यह inspect करें, न कि आपकी configuration file के अनुसार क्या होना चाहिए।

Permissions-Policy क्या नियंत्रित करता है

यह header नामित browser features तक access नियंत्रित करता है। सटीक सूची समय के साथ बदलती रहती है क्योंकि browser APIs बदलती हैं, लेकिन सामान्य directives में शामिल हैं:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• पुराने discussions में interest-cohort, अब अधिकांशतः ऐतिहासिक

एक directive किसी feature को किसी के लिए नहीं, current origin के लिए, या चुने हुए origins के लिए allow कर सकता है। उदाहरण के लिए:

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

इसका अर्थ है कि camera और microphone document और उसके nested browsing contexts के लिए disabled हैं, जबकि geolocation केवल same origin के लिए allowed है।

एक अधिक permissive उदाहरण:

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

यह आपके अपने origin और एक named map provider को geolocation use करने देता है, और आपके अपने origin के साथ एक video provider को fullscreen request करने देता है।

Policy का मूल्यांकन browser करता है। यदि कोई feature disallowed है, तो उस API का उपयोग करने वाला JavaScript fail होना चाहिए या unavailable की तरह behave करना चाहिए। सटीक failure mode API पर निर्भर करता है। कभी promise reject होता है। कभी कोई capability बस usable दिखाई नहीं देती।

यह आपके अपने pages पर क्या lock down कर सकता है

First-party pages पर, Permissions-Policy guardrail के रूप में सबसे उपयोगी है। यह accidental या unexpected code के blast radius को कम करता है।

उदाहरण के लिए, एक marketing page को शायद microphone, camera, Bluetooth, USB, motion sensors, या payment APIs की आवश्यकता नहीं होती। आप इन features को globally deny कर सकते हैं:

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

इससे page पर हर script trustworthy नहीं बन जाती। इसका अर्थ यह है कि यदि कोई tag manager experiment, compromised dependency, या pasted widget किसी restricted API को call करने की कोशिश करता है, तो browser को उसे access grant नहीं करना चाहिए।

कई contributors वाली teams के लिए यह एक उपयोगी default है। यह बातचीत को अस्पष्ट trust से स्पष्ट capability की ओर ले जाता है। यदि किसी future feature को सचमुच camera की आवश्यकता है, तो किसी को policy बदलनी होगी और कारण बताना होगा।

यह सही तरह की friction है।

यह iframes में क्या lock down कर सकता है

Embedded content के आसपास यह header विशेष रूप से उपयोगी हो जाता है।

Browsers पहले से iframes को अलग browsing contexts मानते हैं, लेकिन embedded third-party content फिर भी powerful features request कर सकता है यदि policy और iframe attributes से allow हो। Permissions-Policy parent page को ceiling set करने देता है।

उदाहरण के लिए, यदि आपका page एक video player, support widget, और map embed करता है, तो आप हर frame को हर feature तक access देने से बच सकते हैं। आप fullscreen केवल video frame के लिए और geolocation केवल map frame के लिए allow कर सकते हैं।

समझने के लिए दो layers हैं:

1. HTTP Permissions-Policy header document के लिए policy set करता है।
2. iframe allow attribute किसी frame को specific features delegate कर सकता है, लेकिन केवल parent policy द्वारा permitted सीमा के भीतर।

एक simple iframe इस तरह दिख सकता है:

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

यदि आपका header fullscreen को पूरी तरह deny करता है, तो iframe attribute उस denial को override नहीं कर सकता। यदि आपका header उस origin के लिए fullscreen allow करता है, तो iframe attribute उसे delegate कर सकता है।

यह hierarchy एक कारण है कि header उपयोग करने लायक है। यह platform या security teams को site-wide boundaries set करने का तरीका देता है, जबकि product teams को जहाँ ज़रूरत हो वहाँ specific embeds enable करने देता है।

यह क्या lock down नहीं कर सकता

यहीं teams कभी-कभी header को अधिक शक्तिशाली समझ लेती हैं।

Permissions-Policy content security policy का replacement नहीं है। यह तय नहीं करता कि कौन-सी scripts load हो सकती हैं। यह किसी script को network पर data भेजने से नहीं रोकता। यह HTML sanitize नहीं करता। यह XSS नहीं रोकता। यह form spam block नहीं करता। यदि समस्या form abuse है, तो इस header से नहीं, बल्कि आपका contact form आपकी सबसे बड़ी spam liability क्यों है में बताए गए mechanics से शुरू करें।

यह cookie governance का replacement भी नहीं है। Cookies, local storage, consent, third-party embeds, और browser tracking protections अलग मुद्दे हैं। यदि आप privacy controls को व्यापक रूप से review कर रहे हैं, तो cookie landscape के लिए अलग pass चाहिए; व्यावहारिक बदलाव 2026 में cookies के लिए क्या बदला और इसके बारे में क्या करें में cover किए गए हैं।

सबसे महत्वपूर्ण बात, Permissions-Policy third-party JavaScript को private नहीं बनाता। यदि आप किसी third-party script को अपने first-party page में load करते हैं, तो वह सामान्यतः आपके page privileges के साथ चलता है, अन्य browser constraints और आपके security headers के अधीन। Camera access deny करना अच्छा है। इससे वह script DOM content पढ़ने, user actions observe करने, या allowed network requests करने से नहीं रुकती।

इसके लिए आपको अलग controls चाहिए: careful vendor selection, CSP, sandboxed iframes, जहाँ लागू हो वहाँ Subresource Integrity, data minimization, और उबाऊ लेकिन आवश्यक reviews।

एक sensible default policy

ऐसा कोई universal header नहीं है जो हर site पर फिट हो, लेकिन अधिकांश content और marketing sites restrictive तरीके से शुरू कर सकती हैं।

एक reasonable first pass:

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

फिर केवल वही वापस add करें जो site वास्तव में use करती है।

उदाहरण के लिए:

• Payment Request API use करने वाले store को payment=(self) की आवश्यकता हो सकती है।
• Location finder को geolocation=(self) या trusted map origin की आवश्यकता हो सकती है।
• Conferencing app को camera=(self) और microphone=(self) की आवश्यकता हो सकती है।
• Video-heavy site को fullscreen=(self "https://trusted-video.example") की आवश्यकता हो सकती है।

महत्वपूर्ण बात यह नहीं है कि किसी checklist से बहुत बड़ी policy copy करके काम पूरा मान लिया जाए। अपनी feature inventory से शुरू करें। किन pages को किन browser capabilities की आवश्यकता है? किन embeds को delegation चाहिए? कौन-से features request किए जाने पर surprising लगेंगे?

चीज़ें तोड़े बिना deploy कैसे करें

इसे किसी भी अन्य production header की तरह roll out करें: सोच-समझकर।

1. Feature use की inventory बनाएं

अपने codebase में getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, और wake lock APIs जैसे browser API calls search करें।

फिर third-party embeds check करें। Video, maps, payment, और identity providers के documentation में अक्सर required iframe allow values का उल्लेख होता है।

2. Low-risk environment में शुरू करें

Staging में restrictive header add करें और core journeys test करें। Browser console messages पर ध्यान दें। Browsers अक्सर report करते हैं जब कोई feature permissions policy द्वारा blocked होता है।

3. जहाँ ज़रूरी हो page-specific policies use करें

यदि आपके product में बहुत अलग page types हैं, तो एक global policy force न करें। Blog, checkout, map page, और video room को शायद अलग capabilities चाहिए।

अधिकांश web servers, frameworks, और edge platforms path के आधार पर headers conditionally set कर सकते हैं। यह अक्सर किसी एक feature के लिए पूरी site को कमजोर करने से अधिक साफ़ तरीका है।

4. Real response verify करें

Headers CDNs, reverse proxies, app servers, और middleware द्वारा add, overwritten, duplicated, या stripped हो सकते हैं। Browser DevTools में या command-line tools से final response check करें।

Embedded contexts भी test करें। Top-level page का सही दिखना यह guarantee नहीं करता कि iframe को आपकी intended delegation मिली है।

5. Exceptions document करें

हर allowed feature का owner और reason होना चाहिए। यह bureaucratic लगता है, जब तक छह महीने बाद किसी को याद नहीं रहता कि geolocation को ऐसे vendor domain के लिए क्यों open किया गया था जो अब page पर दिखाई भी नहीं देता।

सामान्य syntax mistakes

Modern header syntax compact है, लेकिन थोड़ा गलत लिखना आसान है।

किसी feature को deny करने के लिए empty parentheses use करें:

Permissions-Policy: microphone=()

Current origin के लिए self use करें:

Permissions-Policy: geolocation=(self)

Specific external origins के लिए quoted origins use करें:

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

पुराने Feature-Policy examples पर rely करने से बचें, जब तक आप जानबूझकर legacy behavior support नहीं कर रहे। पुराने header ने अलग syntax use किया था और आज आपको उसी के आधार पर design नहीं करना चाहिए।

यह भी याद रखें कि browser support directive के अनुसार बदलता है। कोई browser header support कर सकता है लेकिन किसी particular feature directive को नहीं। यह normal है। Header को defense-in-depth measure की तरह treat करें, अपनी एकमात्र privacy या security control की तरह नहीं।

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

💡 इसे आज़माएँ: Get Headers के साथ सत्यापित करें कि आपकी Permissions-Policy अपेक्षित रूप से डिलीवर हो रही है, जो आपके सर्वर द्वारा भेजे जा रहे कच्चे प्रतिक्रिया हेडर दिखाता है।

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

व्यावहारिक privacy value

Permissions-Policy की privacy value यह नहीं है कि यह site को anonymous या tracker-free बना देता है। ऐसा नहीं है।

इसका value यह है कि यह sensitive browser capabilities तक access को narrow करता है। Location, camera, microphone, device sensors, local hardware APIs, और payment flows powerful हैं। अधिकांश pages को इनकी आवश्यकता नहीं होती। कई embedded components को इनके लिए कभी ask करने में सक्षम नहीं होना चाहिए।

यह वास्तविक सुधार है। यह accidental prompts कम करता है, अनावश्यक capability exposure सीमित करता है, और आपकी team को new functionality ship होने पर review करने के लिए एक concrete artifact देता है।

इस header का best version boring होता है: default रूप से restrictive, केवल वहीं loosened जहाँ user-facing feature को इसकी आवश्यकता हो, और normal release process के हिस्से के रूप में tested।