Безопасность и домен 2 мин чтения

Permissions-Policy — доступ к камере, микрофону и геолокации

Заголовок, которым сайт заранее отказывается от возможностей браузера, которые ему не нужны. Страховка от чужих скриптов и виджетов.

Permissions-Policy перечисляет, какими возможностями браузера странице разрешено пользоваться: камерой, микрофоном, геолокацией, датчиками, полноэкранным режимом, платёжным API.

Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=()
  • () — запрещено всем, включая саму страницу;
  • (self) — можно только вашему домену;
  • (self "https://maps.example.com") — вам и указанному стороннему источнику;
  • * — разрешено всем, включая любые встроенные iframe.

Зачем это, если браузер и так спрашивает разрешение

Спрашивает — да, но у пользователя, а не у вас. И спрашивает по инициативе любого кода на странице, включая сторонние скрипты: чат, виджет отзывов, рекламный блок, скомпрометированную библиотеку.

Permissions-Policy убирает саму возможность запроса. Даже если чужой скрипт попытается включить микрофон, браузер откажет молча, не показывая посетителю пугающего окна «Сайт запрашивает доступ к микрофону».

Это защита в глубину: она не заменяет контроль над тем, какие скрипты вы подключаете, но снижает цену ошибки.

Что стоит запретить обычному сайту

Большинству сайтов не нужно ничего из списка:

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()" always;

Исключения понятны: карте с определением местоположения нужен geolocation=(self), сервису видеосвязи — camera=(self), microphone=(self), магазину с Apple Pay или Google Pay — payment=(self).

Важный нюанс: iframe

Политика распространяется на встроенные фреймы. Если вы встраиваете чужую карту или видеоплеер, а политика запрещает нужную им возможность, встроенный сервис перестанет работать. Разрешать нужно явно:

Permissions-Policy: geolocation=(self "https://yandex.ru")

Для отдельного iframe возможности выдаются атрибутом:

<iframe src="https://yandex.ru/map-widget/..." allow="geolocation"></iframe>

Отношение к старому заголовку

Permissions-Policy заменил Feature-Policy с другим синтаксисом. Старый заголовок ещё поддерживается частью браузеров, но писать новый код на нём не нужно.

Как проверить

  • Пункт аудита «Permissions-Policy».
  • Из консоли:
curl -I https://example.ru/ | grep -i permissions-policy
  • F12ApplicationPermissions Policy (в Chrome) показывает действующие правила и то, какие из них унаследованы.

Насколько это срочно

Это не критичная уязвимость, а гигиеническая мера: настраивается за минуту и никогда не мешает, если правильно перечислить исключения. Ставить её имеет смысл вместе с X-Content-Type-Options и Referrer-Policy — все три добавляются одним блоком в конфигурацию сервера.

А что с этим на вашем сайте?

Аудит «Кверху» проверяет этот пункт вместе с остальными пятьюдесятью и показывает конкретику: какие страницы затронуты и что именно исправить. Первая полная проверка проекта — бесплатно.

Проверить сайт бесплатно