Политика разрешений для встроенных возможностей браузера

Политика разрешений ограничивает возможности браузера для документа. Ответ верхнего документа задаёт верхнюю границу, а атрибут allow у iframe делегирует конкретную возможность дочернему источнику. Это граница возможностей, а не выдача пользовательского разрешения, создание устройства или подтверждение бизнес-операции.

Для камеры, микрофона, геолокации и полноэкранного режима записывайте отдельно полученный заголовок, конечный origin, состояние разрешения и видимый результат. Такая модель показывает, на каком этапе возникла проблема, и не требует расширять доступ из-за сбоя одного поставщика. В примере сравниваются https://app.example и https://widget.example.

В примере сравниваются https://app.example и https://widget.example.

Что именно контролирует политика

Спецификация W3C связывает имя возможности со списком origin. Например, Permissions-Policy: geolocation=(self "https://widget.example") разрешает основной origin и названный виджет. iframe также должен соответствовать этому origin: allow="geolocation" не авторизует другой адрес. Проверяйте схему, порт, redirects и всю цепочку предков. Значения по умолчанию зависят от функции; сверяйтесь с MDN.

Результат allowed означает только право попытаться вызвать API. Нужны secure context, жест пользователя, пользовательское или администраторское решение, устройство и параметры функции. navigator.permissions может показывать prompt или granted, пока фрейм заблокирован политикой.

Этап	Доказательство	Что это не доказывает
Origin и контекст	Конечный URL, схема, порт, secure context	Наличие API
Реализация	Узкая проверка интерфейса	Успешный вызов
Политика разрешений	Заголовок, allow, предки, дочерний origin	Разрешение пользователя или устройство
Решение платформы	prompt, отказ, настройка, состояние устройства	Завершение операции
Приложение	Видимый статус и подтверждение с таймаутом	Серверную запись без серверных данных

camera, microphone, geolocation и fullscreen являются разными записями. Разрешайте только необходимое. Не используйте * в multi-tenant системе: проверяйте фактический origin после redirect и поддерживайте обозримый allowlist.

Граница с CSP, COOP и COEP

CSP определяет, какие скрипты, подключения, изображения и фреймы могут загружаться через script-src, connect-src и frame-src. CSP может остановить загрузку до проверки политики разрешений, а загруженный фрейм всё равно может быть заблокирован. Не ослабляйте CSP для исправления делегирования.

COOP меняет связи между окнами и верхнеуровневыми browsing contexts. COEP задаёт условия CORS или CORP для cross-origin ресурсов. Ни один заголовок не выдаёт камеру, микрофон или геолокацию; политика разрешений также не создаёт cross-origin isolation и не делает ресурс CORS-совместимым. Проверяйте сеть и CSP, затем origin и изоляцию, если они нужны, затем header и allow, и только после этого запускайте запрос, требующий жест пользователя.

Эти механизмы не заменяют серверную авторизацию, валидацию, согласие и доступность. Даже разрешённый API требует решения продукта о владельце аккаунта и сроке жизни потока.

Запрос проходит несколько этапов

Сначала проверьте конечный origin и безопасный контекст.

Затем проверьте наличие нужного интерфейса в браузере.

Запишите header, allow, цепочку предков и дочерний origin.

После политики ещё могут вмешаться жест, разрешение, администратор и устройство.

В конце проверьте статус, который видит пользователь.

Контракт встраивания и запасной путь

До изменения заголовка зафиксируйте верхний и конечный дочерний origin, функцию, цель, жест, владельцев header и markup, а также видимую альтернативу. Для камеры оставьте ручную загрузку, для полноэкранного режима используйте обычную навигацию, для геолокации разрешите ручной ввод. Отказ и timeout не должны терять фокус и данные. По завершении остановите tracks и не повторяйте prompt незаметно.

Собственный control/candidate fixture

Разместите /fixtures/permissions-policy/control.html и candidate.html на собственном хосте. Страницы используют один и тот же frame, кнопку и маркер статуса; только candidate получает заголовок делегирования, а control его не получает. Скрипт ребёнка после явного клика выводит policy=blocked или policy=allowed. Разрешение должно быть синтетическим; настоящие координаты не собирайте.

import { test, expect } from '@playwright/test';

const cases = [
  { name: 'control', url: 'https://qa.example.test/fixtures/permissions-policy/control.html', expected: 'blocked' },
  { name: 'candidate', url: 'https://qa.example.test/fixtures/permissions-policy/candidate.html', expected: 'allowed' },
];

for (const scenario of cases) {
  test(`Permissions Policy ${scenario.name}`, async ({ page }) => {
    try {
      const response = await page.goto(scenario.url, { waitUntil: 'domcontentloaded', timeout: 8000 });
      expect(response?.ok(), `HTTP-ответ ${scenario.name}`).toBeTruthy();
    } catch (error) {
      throw new Error(`NETWORK_ERROR до проверки политики: ${error.message}`);
    }
    await page.getByRole('button', { name: 'Request location' }).click();
    await expect(page.getByTestId('policy-result')).toHaveText(new RegExp(`^${scenario.expected}$`), { timeout: 5000 });
  });
}

Timeout навигации или статуса означает отсутствие доказательства в заданное время, а не policy denial. DNS, сертификат, HTTP-ошибка и отсутствующий маршрут должны оставаться NETWORK_ERROR, а не превращаться в blocked. Закройте context и удалите временные данные в teardown, сохранив первую ошибку. Атрибуция обеспечивается одинаковыми origin, frame, кнопкой и маркером: меняется только делегирование.

Развёртывание и диагностика

На стенде используйте рабочую маршрутизацию и origins. После redirect, CDN, фонового сетевого обработчика и proxy проверьте фактический header и конечный allow. Классифицируйте первое событие: неверный header, это конфигурация; загруженный frame со blocked, это цепочка политики; allowed и отказ, это разрешение или состояние браузера; ошибка после API, это приложение; timeout или DNS, это доступность.

Проверьте удаление функции, неожиданный origin, redirect на неразрешённый origin и вложенный frame без делегирования. Храните прежние header, markup и версию для rollback. Не лечите сбой удалением всего заголовка или добавлением *; временное исключение должно назвать функцию, origin, владельца и срок.

Что может проверить BotBrowser

BotBrowser может запускать авторизованные сценарии в контролируемых browser contexts, изолировать синтетическое состояние и сравнивать видимые результаты на объявленной сборке. BotBrowser не может изменить доставленную политику или выдать разрешение. В документации изоляции описаны отдельные контексты для независимых сессий.

BotBrowser не создаёт и не разворачивает заголовки, не меняет origins, не выдаёт разрешения, не предоставляет устройства, не заменяет CSP/COOP/COEP, не исправляет ответ поставщика и не доказывает удалённую бизнес-операцию. Авторитетны спецификация W3C и фактически доставленные заголовки. За дизайн политики отвечают владельцы приложения, инфраструктуры, поставщика и согласия.

Не записывайте cookies, учётные данные, координаты или содержимое потоков.

Для каждой попытки используйте отдельную синтетическую учётную запись.

После смены поставщика заново проверьте конечный origin.

У временного исключения должны быть владелец и срок окончания.

Откат должен вернуть header и markup вместе.

В поддержку передавайте первую не пройденную дверь, а не общую метку ошибки.

См. руководство по безопасным контекстам.

См. руководство CSP.

См. руководство изоляции между origin.

Согласие должно объяснять цель до жеста пользователя.

Источники

• W3C: политика разрешений
• MDN: политика разрешений
• MDN: атрибут allow
• MDN: CSP
• MDN: COOP
• MDN: COEP
• BotBrowser: изоляция

BotBrowser Team