Безопасные контексты: почему мощным API браузера нужен HTTPS

Безопасный контекст: среда, в которой браузер может обоснованно доверять целостности источника страницы и его предкам. Стандарт Secure Contexts использует эту классификацию для ограничения функций, способных раскрыть личные данные или получить доступ к устройству. В рабочей среде обычно нужен HTTPS, но он является только условием допуска: он не выдаёт разрешение, не отменяет политику встраивания, не создаёт активацию пользователя, не гарантирует наличие API и не доказывает успешность удалённой операции.

Что означает безопасный контекст

Спецификация W3C Secure Contexts описывает классификацию, а не значок замка и не общую гарантию безопасности каждого скрипта. Типичный случай: верхнеуровневая HTTPS-страница с действительным сертификатом. Если её встраивает ненадёжный предок, классификация может измениться. window.isSecureContext сообщает состояние текущего глобального объекта, но не говорит, реализован ли интерфейс, разрешён ли он политикой, согласился ли пользователь и завершится ли вызов успешно.

Loopback-источники, например http://localhost, обычно считаются заслуживающими доверия в разработке даже без публичного сертификата. Это исключение не делает удалённый HTTP безопасным. Фиксируйте фактический URL и версию браузера, поскольку детали реализации меняются. Камера, микрофон, геолокация, буфер обмена и операции с учётными данными называют мощными возможностями, но каждая спецификация добавляет свои требования: активация, разрешение, видимость документа, оборудование, политика или ответ сервера.

Допуск не равен разрешению

Разделяйте пять ворот: контекст допускает раскрытие API; браузер и платформа его реализуют; цепочка iframe и политика разрешений разрешают использование; пользователь, браузер или администратор устройства дают разрешение; сам вызов выполняется по своим правилам и результат проверяется приложением. В отчётах различайте не допущено, не поддерживается, заблокировано политикой, разрешение отклонено, отменено, операция завершилась ошибкой и завершено.

Ворота	Проверка	Что записать
Контекст	window.isSecureContext и конечный источник	Допущен или не допущен
Политика	Заголовок ответа и allow у iframe	Разрешено или заблокировано
Разрешение	Решение пользователя, браузера или устройства	Выдано, отклонено или ожидается
Операция	Интерфейс, жест, оборудование и результат приложения	Завершена или завершилась ошибкой

Политика разрешений (политика разрешений W3C) задаёт верхнюю границу в заголовке ответа, а allow у iframe делегирует конкретной странице. Делегирование не является выдачей пользовательского разрешения. Проверяйте заголовок, атрибут, источник дочернего документа и спецификацию функции вместе. Источник состоит из схемы, хоста и порта; изменение любого из них разделяет хранилища, cookies, разрешения и service workers. sandbox может дать frame непрозрачный источник.

Активация пользователя независима. Запускайте вызов из видимого элемента, доступного с клавиатуры, объясняйте причину и сохраняйте альтернативный путь. Не показывайте чувствительный запрос автоматически при загрузке.

HTTPS, localhost и встроенные документы

Сравнивайте полный URL и всю цепочку перенаправлений. После загрузки конечного HTTPS-документа проверяйте location.origin и isSecureContext. Между локальной и рабочей средой также меняются заголовки, прокси, история разрешений, версия браузера и структура frame. HTTPS-iframe может не получить делегирование, а HTTPS-страница может загрузить активный HTTP-ресурс, который браузер заблокирует. Не используйте allow="*" как отладочный обход: указывайте только нужную функцию и ожидаемый источник.

Политика одного источника, cross-origin isolation и политика разрешений отвечают на разные вопросы. Включение одного механизма не заменяет остальные. Для каждого документа записывайте источник, результат безопасного контекста, заголовок Permissions-Policy и allow.

Детерминированная fixture

Эта fixture проверяет только классификацию и не запрашивает реальное устройство:

async function checkSecureContext(expected) {
  const host = document.createElement('section');
  const status = document.createElement('output');
  status.setAttribute('aria-live', 'polite');
  host.append(status);
  document.body.append(host);
  try {
    const actual = window.isSecureContext;
    const passed = actual === expected;
    status.textContent = `${passed ? 'PASS' : 'FAIL'}: expected ${expected}; observed ${actual}`;
    console.assert(passed, status.textContent);
    return { passed, actual, visibleResult: status.textContent };
  } finally {
    host.remove();
  }
}
await checkSecureContext(true);

Ожидаемое значение задаётся конфигурацией теста, а не измеренным значением. Для iframe запускайте fixture в дочернем документе и передавайте результат через postMessage; родитель обязан проверить event.origin. Покройте HTTPS, удалённый HTTP при возможности, localhost и целевой дочерний источник. Записывайте точный URL, браузер, политики, связь frame и видимый результат. Узлы DOM, временные данные и изолированные контексты удаляйте в finally.

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

Развёртывание, наблюдение и откат

Перед выпуском проверьте сертификаты, редиректы, reverse proxy, Content-Security-Policy, Permissions-Policy и allow. После фиксации заголовков запустите fixture на staging и повторите те же проверки на production-кандидате. Храните отчёт без учётных данных и сырых prompt: URL, версию браузера, результаты, политики и дочерний источник.

Предусмотрите запасной путь: ручной ввод района вместо геолокации, обычную загрузку вместо API буфера обмена или инструкции для работы без устройства. Сохраняйте введённые данные и доступность. Ошибку транспорта нельзя называть отказом пользователя. Откатывайте минимальный компонент: хостинг для сертификата и редиректа, конфигурацию для заголовка, интеграцию для делегирования и приложение для запасного пути. Не возвращайтесь к HTTP и не открывайте политику широко; после отката повторите ту же fixture.

Что проверяет BotBrowser

BotBrowser предоставляет контролируемые контексты для разрешённых страниц владельца. В них можно открыть fixture на объявленных источниках, наблюдать isSecureContext, проверять запасной путь и сравнивать видимые результаты между поддерживаемыми версиями. Документация изоляции нескольких аккаунтов описывает отдельные контексты для повторяемых сценариев. Для этой темы BotBrowser поддерживает изолированный контекст, который загружает собственную HTTPS fixture и сообщает видимый результат безопасного контекста, но не может сделать небезопасный источник доверенным и не может выдать разрешение пользователя.

BotBrowser не делает удалённый HTTP доверенным, не выдаёт разрешения, не отменяет политику разрешений, не добавляет отсутствующее оборудование и не гарантирует API на каждой платформе. Он не заменяет требования W3C, сертификаты, заголовки, проверки приложения или production-мониторинг. Положительный результат описывает видимое поведение в записанных условиях; HTTPS, встраивание и запасной путь остаются ответственностью владельца сайта.

См. также руководство по разрешениям и совместимость API и запасные пути.

В конфигурации сохраняйте конечный источник.

Фиксируйте версию проверенного браузера.

Заголовок политики является частью тестового случая.

Источник iframe проверяйте явно.

Ожидание задавайте до измерения.

Fixture не должна запрашивать чувствительные данные.

Жест пользователя проверяется отдельно.

Отказ нельзя смешивать с ошибкой TLS.

Смешанный контент исправляется на сервере.

Запасной путь сохраняет введённые данные.

Он должен работать с клавиатурой.

В отчёте не хранятся учётные данные.

Откат сохраняет HTTPS.

Fixture повторяется после изменения заголовков.

Изолированные контексты всегда очищаются.

Локальный успех не является доказательством для production.

Источники

• W3C Secure Contexts
• MDN: Secure contexts
• W3C: политика разрешений
• BotBrowser: изоляция нескольких аккаунтов