Permissions-Policy header আসলে কী লক ডাউন করতে পারে

সংক্ষিপ্ত সংস্করণ

Permissions-Policy একটি HTTP response header, যা কোনো site-কে নির্দিষ্ট browser feature-এ access সীমিত করতে দেয়: camera, microphone, geolocation, fullscreen, payment, sensors, এবং আরও অনেক ছোট API।

এটি কোনো general privacy shield নয়। এটি সব tracking থামাবে না, cookies block করবে না, network requests আটকাবে না, বা third-party JavaScript-কে safe বানাবে না। এটি যেটা ভালো করতে পারে তা scope-এ ছোট, কিন্তু তবুও মূল্যবান: আপনার নিজের page এবং embedded frame-গুলোর জন্য উপলভ্য browser capability কমানো।

এটি গুরুত্বপূর্ণ, কারণ modern website তৈরি হয় analytics snippets, media embeds, chat widgets, consent managers, advertising scripts, maps, payment flows, এবং internal experiments একসঙ্গে জুড়ে। এসব component-এর বেশিরভাগের powerful device API-তে access দরকার হয় না। ভালো policy সেটি স্পষ্ট করে।

আপনি যদি production-এ header review করে থাকেন, এই কাজের সঙ্গে actual response সরাসরি check করুন। আমাদের production-এ redirects এবং HTTP headers debug করার ছোট toolkit guide-এ এখানে যে অভ্যাসটি গুরুত্বপূর্ণ তা covered হয়েছে: আপনার configuration file কী হওয়া উচিত বলছে তা নয়, browser আসলে কী receive করছে সেটি inspect করুন।

Permissions-Policy কী নিয়ন্ত্রণ করে

Header named browser feature-এ access নিয়ন্ত্রণ করে। exact list সময়ের সঙ্গে বদলায়, কারণ browser API বদলায়, তবে common directive-এর মধ্যে আছে:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• পুরোনো আলোচনায় interest-cohort, এখন বেশিরভাগই historical

একটি directive কোনো feature কারও জন্য নয়, current origin-এর জন্য, বা selected origin-এর জন্য allow করতে পারে। উদাহরণ:

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

এর মানে camera এবং microphone document ও তার nested browsing context-গুলোর জন্য disabled, আর geolocation শুধু same origin-এর জন্য allowed।

আরও permissive একটি example:

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

এটি আপনার নিজের origin এবং একটি named map provider-কে geolocation ব্যবহার করতে দেয়, এবং আপনার নিজের origin plus একটি video provider-কে fullscreen request করতে দেয়।

Policy browser evaluate করে। কোনো feature disallow করা হলে, সেই API ব্যবহার করা JavaScript fail করা বা unavailable হিসেবে behave করা উচিত। exact failure mode API-এর ওপর নির্ভর করে। কখনও promise reject করে। কখনও capabilityটি simply usable বলে দেখা যায় না।

আপনার নিজের page-এ এটি কী lock down করতে পারে

First-party page-এ Permissions-Policy guardrail হিসেবে সবচেয়ে useful। এটি accidental বা unexpected code-এর blast radius কমায়।

একটি marketing page-এর, উদাহরণস্বরূপ, সম্ভবত microphone, camera, Bluetooth, USB, motion sensors, বা payment APIs দরকার হয় না। আপনি এই feature-গুলো 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 করা উচিত নয়।

অনেক contributor থাকা team-এর জন্য এটি একটি useful default। এটি conversation-কে vague trust থেকে explicit capability-তে নিয়ে যায়। ভবিষ্যতের কোনো feature-এর সত্যিই camera দরকার হলে, কাউকে policy বদলাতে হবে এবং কেন দরকার তা explain করতে হবে।

এটাই সঠিক ধরনের friction।

iframe-এ এটি কী lock down করতে পারে

Embedded content-এর ক্ষেত্রে headerটি বিশেষভাবে useful হয়ে ওঠে।

Browsers ইতিমধ্যেই iframe-কে separate browsing context হিসেবে treat করে, কিন্তু embedded third-party content এখনও policy এবং iframe attribute দ্বারা allowed হলে powerful feature request করতে পারে। Permissions-Policy parent page-কে একটি ceiling set করতে দেয়।

উদাহরণস্বরূপ, আপনার page যদি video player, support widget, এবং map embed করে, তাহলে আপনি প্রতিটি frame-কে প্রতিটি feature-এ access দেওয়া এড়াতে পারেন। আপনি হয়তো শুধু video frame-এর জন্য fullscreen এবং শুধু map frame-এর জন্য geolocation allow করবেন।

বোঝার জন্য দুটি layer আছে:

1. HTTP Permissions-Policy header document-এর জন্য policy set করে।
2. iframe allow attribute কোনো frame-এ specific feature delegate করতে পারে, তবে parent policy যা permit করে তার মধ্যেই।

একটি 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 team-কে site-wide boundary set করার উপায় দেয়, আবার product team-কে দরকারি জায়গায় specific embed enable করার সুযোগও রাখে।

এটি কী lock down করতে পারে না

এখানেই team-গুলো কখনও কখনও headerটির ক্ষমতা বেশি ধরে নেয়।

Permissions-Policy কোনো content security policy-এর replacement নয়। এটি কোন script load হতে পারবে তা decide করে না। এটি কোনো script-কে network-এ data পাঠানো থেকে থামায় না। এটি HTML sanitize করে না। এটি XSS prevent করে না। এটি form spam block করে না। যদি form abuse সমস্যা হয়, তাহলে এই header দিয়ে নয়, কেন আপনার contact form আপনার সবচেয়ে বড় spam liability-তে বর্ণিত mechanics দিয়ে শুরু করুন।

এটি cookie governance-এর replacement-ও নয়। Cookies, local storage, consent, third-party embeds, এবং browser tracking protections আলাদা issue। আপনি যদি privacy controls বিস্তৃতভাবে review করেন, cookie landscape-এর নিজস্ব pass দরকার; practical changes covered আছে 2026 সালে cookies-এর জন্য কী বদলেছে এবং এ নিয়ে কী করবেন-এ।

সবচেয়ে গুরুত্বপূর্ণ, Permissions-Policy third-party JavaScript-কে private বানায় না। আপনি যদি third-party script আপনার first-party page-এ load করেন, সেটি সাধারণত আপনার page privileges নিয়েই run করে, অন্যান্য browser constraint এবং আপনার security header-এর subject হিসেবে। Camera access deny করা ভালো। কিন্তু সেটি ওই script-কে DOM content পড়া, user actions observe করা, বা allowed network request করা থেকে থামায় না।

এর জন্য আলাদা control দরকার: careful vendor selection, CSP, sandboxed iframes, applicable হলে Subresource Integrity, data minimization, এবং বিরক্তিকর হলেও necessary reviews।

একটি sensible default policy

প্রতিটি site-এর জন্য মানানসই universal header নেই, তবে বেশিরভাগ content এবং marketing site restrictive ভাবে শুরু করতে পারে।

একটি reasonable first pass:

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

তারপর শুধু site আসলে যা ব্যবহার করে তা add back করুন।

উদাহরণস্বরূপ:

• Payment Request API ব্যবহার করা 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 করে done বলা নয়। আপনার feature inventory দিয়ে শুরু করুন। কোন page-এর কোন browser capability দরকার? কোন embed-এর delegation দরকার? কোন feature request করা হলে তা surprising হবে?

কীভাবে কিছু না ভেঙে deploy করবেন

এটি অন্য যেকোনো production header-এর মতোই roll out করুন: deliberately।

1. Feature use inventory করুন

আপনার codebase-এ getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, এবং wake lock APIs-এর মতো browser API call search করুন।

তারপর third-party embed check করুন। Video, maps, payment, এবং identity provider-এর documentation প্রায়ই required iframe allow value উল্লেখ করে।

2. Low-risk environment-এ শুরু করুন

Staging-এ restrictive header add করুন এবং core journey test করুন। Browser console message-এ নজর দিন। কোনো feature permissions policy দ্বারা blocked হলে browsers প্রায়ই report করে।

3. দরকার হলে page-specific policy ব্যবহার করুন

আপনার product-এ page type খুব আলাদা হলে একটি global policy জোর করে চাপাবেন না। Blog, checkout, map page, এবং video room-এর সম্ভবত আলাদা capability দরকার।

বেশিরভাগ web server, framework, এবং edge platform path অনুযায়ী conditionally header set করতে পারে। একটি feature-এর জন্য পুরো site দুর্বল করার চেয়ে এটি প্রায়ই cleaner।

4. Real response verify করুন

CDN, reverse proxy, app server, এবং middleware দ্বারা header add, overwrite, duplicate, বা strip হতে পারে। Browser DevTools বা command-line tools দিয়ে final response check করুন।

Embedded context-ও test করুন। Top-level page ঠিক দেখা গেলেই নিশ্চিত হওয়া যায় না যে iframe আপনার intended delegation receive করেছে।

5. Exception document করুন

প্রতিটি allowed feature-এর owner এবং reason থাকা উচিত। এটি bureaucratic শোনায়, যতক্ষণ না ছয় মাস পরে কেউ মনে করতে পারে না কেন geolocation এমন vendor domain-এর জন্য খোলা হয়েছিল যা page-এ আর দেখা যায় না।

Common syntax mistake

Modern header syntax compact, তবে সামান্য ভুল করা সহজ।

কোনো feature deny করতে empty parentheses ব্যবহার করুন:

Permissions-Policy: microphone=()

Current origin-এর জন্য self ব্যবহার করুন:

Permissions-Policy: geolocation=(self)

Specific external origin-এর জন্য quoted origins ব্যবহার করুন:

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

আপনি যদি intentionally legacy behavior support না করেন, পুরোনো Feature-Policy example-এর ওপর rely করা এড়ান। পুরোনো header একটি ভিন্ন syntax ব্যবহার করত এবং আজকের design-এর ভিত্তি হিসেবে সেটি নেওয়া উচিত নয়।

আরও মনে রাখুন, directive অনুযায়ী browser support vary করে। কোনো browser header support করতে পারে, কিন্তু particular feature directive support নাও করতে পারে। এটি normal। Headerটিকে defense-in-depth measure হিসেবে treat করুন, আপনার একমাত্র privacy বা security control হিসেবে নয়।

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

💡 এটি চেষ্টা করুন: Get Headers দিয়ে যাচাই করুন যে আপনার Permissions-Policy প্রত্যাশিতভাবে সরবরাহ করা হচ্ছে কি না, যা আপনার সার্ভার পাঠাচ্ছে এমন কাঁচা প্রতিক্রিয়া হেডারগুলি দেখায়।

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

Practical privacy value

Permissions-Policy-এর privacy value এই নয় যে এটি site-কে anonymous বা tracker-free বানায়। তা করে না।

এর value হলো এটি sensitive browser capability-তে access narrow করে। Location, camera, microphone, device sensors, local hardware APIs, এবং payment flows powerful। বেশিরভাগ page-এর এগুলো দরকার নেই। অনেক embedded component-এর কখনও এগুলো request করতে পারা উচিত নয়।

এটি বাস্তব improvement। এটি accidental prompt কমায়, unnecessary capability exposure সীমিত করে, এবং নতুন functionality ship হলে review করার জন্য আপনার team-কে একটি concrete artifact দেয়।

এই header-এর best version boring: default-এ restrictive, শুধু user-facing feature দরকার হলে loosened, এবং normal release process-এর অংশ হিসেবে tested।