Permissions-Policy başlığının gerçekten neleri kilitleyebileceği

Kısa versiyon

Permissions-Policy, bir sitenin belirli tarayıcı özelliklerine erişimi sınırlamasını sağlayan bir HTTP yanıt başlığıdır: kamera, mikrofon, konum, tam ekran, ödeme, sensörler ve daha küçük API’lerden oluşan uzun bir liste.

Genel amaçlı bir gizlilik kalkanı değildir. Tüm izlemeyi durdurmaz, çerezleri engellemez, ağ isteklerini önlemez veya üçüncü taraf JavaScript’i güvenli hale getirmez. İyi yaptığı şey daha dar kapsamlıdır ve yine de değerlidir: kendi sayfalarınızın ve gömülü frame’lerin kullanabileceği tarayıcı kabiliyetlerini azaltmak.

Bu önemlidir, çünkü modern web siteleri analytics parçacıkları, medya embed’leri, sohbet widget’ları, onay yöneticileri, reklam script’leri, haritalar, ödeme akışları ve dahili deneylerle bir araya getirilir. Bu bileşenlerin çoğunun güçlü cihaz API’lerine erişmesi gerekmez. İyi bir policy bunu açık hale getirir.

Production’da başlıkları zaten gözden geçiriyorsanız, bu çalışmayı gerçek yanıtın doğrudan kontrolüyle eşleştirin. Production’da redirect’leri ve HTTP headers’ı debug etmek için küçük bir araç seti rehberimiz burada önemli olan alışkanlığı ele alır: yapılandırma dosyanızın olması gerektiğini söylediği şeyi değil, tarayıcının gerçekten ne aldığını inceleyin.

Permissions-Policy neleri kontrol eder

Başlık, adlandırılmış tarayıcı özelliklerine erişimi kontrol eder. Kesin liste zaman içinde değişir, çünkü tarayıcı API’leri değişir; ancak yaygın directives şunları içerir:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• Eski tartışmalarda interest-cohort, artık çoğunlukla tarihsel

Bir directive, bir özelliği hiç kimse için, mevcut origin için veya seçili origin’ler için izinli hale getirebilir. Örneğin:

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

Bu, kamera ve mikrofonun belge ve onun iç içe browsing context’leri için devre dışı bırakıldığı, konumun ise yalnızca aynı origin için izinli olduğu anlamına gelir.

Daha izin verici bir örnek:

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

Bu, kendi origin’inizin ve adı belirtilen bir harita sağlayıcısının konumu kullanmasına, ayrıca kendi origin’inizin ve bir video sağlayıcısının tam ekran isteğinde bulunmasına izin verir.

Policy tarayıcı tarafından değerlendirilir. Bir özelliğe izin verilmiyorsa, o API’yi kullanan JavaScript başarısız olmalı veya özellik kullanılamıyormuş gibi davranmalıdır. Kesin başarısızlık biçimi API’ye bağlıdır. Bazen bir promise reddedilir. Bazen bir kabiliyet kullanılabilir görünmez.

Kendi sayfalarınızda neleri kilitleyebilir

First-party sayfalarda Permissions-Policy en çok bir güvenlik korkuluğu olarak yararlıdır. Kazara veya beklenmedik kodun etki alanını daraltır.

Örneğin bir marketing sayfasının muhtemelen mikrofon, kamera, Bluetooth, USB, hareket sensörleri veya ödeme API’lerine ihtiyacı yoktur. Bu özellikleri global olarak reddedebilirsiniz:

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

Bu, sayfadaki her script’i güvenilir yapmaz. Şu anlama gelir: bir tag manager deneyi, ele geçirilmiş bir dependency veya yapıştırılmış bir widget kısıtlanmış bir API’yi çağırmaya çalışırsa, tarayıcı ona erişim vermemelidir.

Çok sayıda katkı sağlayıcısı olan ekipler için bu kullanışlı bir varsayılandır. Konuşmayı belirsiz güvenden açık kabiliyete taşır. Gelecekteki bir özellik gerçekten kameraya ihtiyaç duyarsa, birinin policy’yi değiştirmesi ve nedenini açıklaması gerekir.

Bu doğru türde bir sürtünmedir.

iframe’lerde neleri kilitleyebilir

Başlık, gömülü içerik söz konusu olduğunda özellikle yararlı hale gelir.

Tarayıcılar iframe’leri zaten ayrı browsing context’ler olarak ele alır, ancak gömülü üçüncü taraf içerik, policy ve iframe öznitelikleri izin veriyorsa güçlü özellikleri yine de isteyebilir. Permissions-Policy, parent sayfanın bir üst sınır belirlemesini sağlar.

Örneğin sayfanız bir video oynatıcı, bir destek widget’ı ve bir harita gömüyorsa, her frame’e her özelliğe erişim vermekten kaçınabilirsiniz. Tam ekranı yalnızca video frame’i için, konumu yalnızca harita frame’i için izinli hale getirebilirsiniz.

Anlaşılması gereken iki katman vardır:

1. HTTP Permissions-Policy başlığı belge için policy belirler.
2. iframe allow özniteliği belirli özellikleri bir frame’e devredebilir, ancak yalnızca parent policy’nin izin verdiği sınırlar içinde.

Basit bir iframe şöyle görünebilir:

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

Başlığınız tam ekranı tamamen reddediyorsa, iframe özniteliği bu reddi geçersiz kılamaz. Başlığınız o origin için tam ekrana izin veriyorsa, iframe özniteliği bunu devredebilir.

Bu hiyerarşi, başlığın kullanılmaya değer olmasının nedenlerinden biridir. Platform veya güvenlik ekiplerine site genelinde sınırlar belirleme yolu verirken, ürün ekiplerinin gerektiğinde belirli embed’leri etkinleştirmesine de olanak tanır.

Neleri kilitleyemez

Ekiplerin bazen bu başlığı olduğundan fazla değerlendirdiği yer burasıdır.

Permissions-Policy, content security policy’nin yerini almaz. Hangi script’lerin yüklenebileceğine karar vermez. Bir script’in ağ üzerinden veri göndermesini durdurmaz. HTML’i temizlemez. XSS’i önlemez. Form spam’ini engellemez. Sorun form kötüye kullanımıysa, bu başlıkla değil, iletişim formunuzun neden en büyük spam yükümlülüğünüz olduğu yazısında açıklanan mekaniklerle başlayın.

Ayrıca çerez yönetişiminin yerini de almaz. Çerezler, local storage, onay, üçüncü taraf embed’leri ve tarayıcı izleme korumaları ayrı konulardır. Gizlilik kontrollerini geniş kapsamda gözden geçiriyorsanız, çerez ortamı kendi başına ele alınmayı hak eder; pratik değişiklikler 2026’da çerezler için neler değişti ve ne yapmalı yazısında ele alınmıştır.

En önemlisi, Permissions-Policy üçüncü taraf JavaScript’i özel hale getirmez. Bir üçüncü taraf script’i first-party sayfanıza yüklerseniz, genellikle sayfanızın ayrıcalıklarıyla çalışır; diğer tarayıcı kısıtlarına ve güvenlik başlıklarınıza tabidir. Kamera erişimini reddetmek iyidir. Ancak bu, o script’in DOM içeriğini okumasını, kullanıcı eylemlerini gözlemlemesini veya izin verilen ağ isteklerini yapmasını durdurmaz.

Bunun için farklı kontrollere ihtiyacınız vardır: dikkatli vendor seçimi, CSP, sandboxed iframes, uygun olduğu yerlerde Subresource Integrity, veri minimizasyonu ve sıkıcı ama gerekli incelemeler.

Makul bir varsayılan policy

Her siteye uyan evrensel bir başlık yoktur, ancak çoğu içerik ve marketing sitesi kısıtlayıcı başlayabilir.

Makul bir ilk deneme:

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

Ardından yalnızca sitenin gerçekten kullandıklarını geri ekleyin.

Örneğin:

• Payment Request API kullanan bir mağazanın payment=(self) ihtiyacı olabilir.
• Konum bulucu bir özelliğin geolocation=(self) veya güvenilir bir harita origin’i gerekebilir.
• Bir konferans uygulamasının camera=(self) ve microphone=(self) ihtiyacı olabilir.
• Video ağırlıklı bir sitenin fullscreen=(self "https://trusted-video.example") ihtiyacı olabilir.

Önemli olan, bir checklist’ten devasa bir policy kopyalayıp işi bitmiş saymamaktır. Özellik envanterinizle başlayın. Hangi sayfalar hangi tarayıcı kabiliyetlerine ihtiyaç duyuyor? Hangi embed’ler delegasyon gerektiriyor? Hangi özelliklerin istenmesi şaşırtıcı olurdu?

Bir şeyleri bozmadan nasıl dağıtılır

Bunu diğer production başlıkları gibi yayınlayın: bilinçli bir şekilde.

1. Özellik kullanımını envantere alın

Kod tabanınızda getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB ve wake lock API’leri gibi tarayıcı API çağrılarını arayın.

Ardından üçüncü taraf embed’lerini kontrol edin. Video, harita, ödeme ve kimlik sağlayıcılarının dokümantasyonu genellikle gerekli iframe allow değerlerinden bahseder.

2. Düşük riskli bir ortamda başlayın

Staging’e kısıtlayıcı bir başlık ekleyin ve temel kullanıcı akışlarını test edin. Tarayıcı console mesajlarına dikkat edin. Tarayıcılar genellikle bir özellik permissions policy tarafından engellendiğinde bunu bildirir.

3. Gerektiğinde sayfaya özel policy’ler kullanın

Ürününüz çok farklı sayfa türlerine sahipse tek bir global policy’yi zorlamayın. Bir blog, checkout, harita sayfası ve video odası muhtemelen farklı kabiliyetlere ihtiyaç duyar.

Çoğu web server, framework ve edge platformu, path’e göre koşullu başlık ayarlayabilir. Bu, çoğu zaman tek bir özellik için tüm siteyi zayıflatmaktan daha temizdir.

4. Gerçek yanıtı doğrulayın

Başlıklar CDN’ler, reverse proxy’ler, app server’lar ve middleware tarafından eklenebilir, üzerine yazılabilir, çoğaltılabilir veya kaldırılabilir. Nihai yanıtı browser DevTools’ta veya command-line araçlarıyla kontrol edin.

Gömülü context’leri de test edin. Top-level sayfanın doğru görünmesi, bir iframe’in amaçladığınız delegasyonu aldığı anlamına gelmez.

5. İstisnaları belgeleyin

İzin verilen her özelliğin bir sahibi ve bir nedeni olmalıdır. Bu, altı ay sonra geolocation’ın artık sayfada görünmeyen bir vendor domain’i için neden açıldığını kimse hatırlamayınca bürokratik gelmemeye başlar.

Yaygın syntax hataları

Modern başlık syntax’ı kompakttır, ancak küçük hatalar yapmaya açıktır.

Bir özelliği reddetmek için boş parantez kullanın:

Permissions-Policy: microphone=()

Mevcut origin için self kullanın:

Permissions-Policy: geolocation=(self)

Belirli harici origin’ler için tırnak içindeki origin’leri kullanın:

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

Eski Feature-Policy örneklerine, bilerek legacy davranışı desteklemiyorsanız, güvenmekten kaçının. Eski başlık farklı bir syntax kullanıyordu ve bugün tasarımınızı bunun üzerine kurmamalısınız.

Tarayıcı desteğinin directive’e göre değiştiğini de unutmayın. Bir tarayıcı başlığı destekleyip belirli bir feature directive’i desteklemeyebilir. Bu normaldir. Başlığı tek gizlilik veya güvenlik kontrolünüz olarak değil, defense-in-depth önlemi olarak ele alın.

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

💡 Bunu deneyin: Permissions-Policy’nizin amaçlandığı gibi iletildiğini Get Headers ile doğrulayın; bu, sunucunuzun gönderdiği ham yanıt başlıklarını gösterir.

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

Pratik gizlilik değeri

Permissions-Policy’nin gizlilik değeri, bir siteyi anonim veya tracker’sız hale getirmesi değildir. Bunu yapmaz.

Değeri, hassas tarayıcı kabiliyetlerine erişimi daraltmasındadır. Konum, kamera, mikrofon, cihaz sensörleri, yerel donanım API’leri ve ödeme akışları güçlüdür. Çoğu sayfanın bunlara ihtiyacı yoktur. Birçok gömülü bileşenin bunları istemeye asla gücü yetmemelidir.

Bu gerçek bir iyileştirmedir. Kazara çıkan prompt’ları azaltır, gereksiz kabiliyet maruziyetini sınırlar ve yeni işlevsellik yayınlandığında ekibinize gözden geçirebileceği somut bir artifact verir.

Bu başlığın en iyi hali sıkıcı olandır: varsayılan olarak kısıtlayıcı, yalnızca kullanıcıya dönük bir özellik gerektirdiğinde gevşetilmiş ve normal release sürecinin parçası olarak test edilmiş.