Заголовки Fetch Metadata: контекст CSRF и приватность

BotBrowser может повторить разрешённый синтетический сценарий с объявленными браузером, профилем, маршрутом и проверкой. Он не превращает Sec-Fetch-* в личность, не заменяет аутентификацию, не доказывает намерение пользователя и не гарантирует одинаковые заголовки у всех браузеров и посредников. Используйте Fetch Metadata как ограниченный сигнал контекста, отдельно от CSRF-токена, cookie, авторизации и проверки приватности.

TL;DR

• Fetch Metadata описывает связь сайтов, назначение, режим и навигацию, но не является учётными данными.
• Sec-Fetch-Site может усилить CSRF-политику и отклонить неожиданные межсайтовые изменения состояния.
• Заголовки могут отсутствовать; нужна явная ветка совместимости для старых и небраузерных клиентов.
• Это метаданные запроса: ограничьте журналы и не превращайте их в отпечаток или идентификатор.
• Проверьте матрицу same-origin, same-site, cross-site, верхней навигации и клиента без этих полей.

Contents

• Что описывает Fetch Metadata
• Значение каждого заголовка
• Построение CSRF-политики
• Клиенты без заголовков и необычные случаи
• Границы приватности и наблюдаемости
• Копируемая политика
• Тестирование с BotBrowser
• Практический вывод
• FAQ

Что описывает Fetch Metadata

Спецификация W3C Fetch Metadata определяет контекст браузерного fetch. Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User и Sec-Fetch-Dest различают навигацию и ресурс, а также same-origin, same-site и cross-site отношения. Они не говорят, кто использует браузер, одобрил ли действие пользователь и разрешён ли аккаунт. Same-origin-запрос может исходить из скомпрометированной страницы, а cross-site может быть публичной картинкой или легитимным OAuth-возвратом. Нативные клиенты, старые браузеры, worker, расширение или proxy могут не отправлять поля. Серверная аутентификация обязательна.

Sec-Fetch-Site принимает значения same-origin, same-site, cross-site и none; same-site не означает same-origin. Sec-Fetch-Mode и Sec-Fetch-Dest помогают распознать форму подресурса. Sec-Fetch-User: ?1 означает лишь активированную навигацию, а не одобрение платежа. Сверяйтесь с MDN Fetch metadata и MDN Sec-Fetch-Site, фиксируя версию браузера.

Значение каждого заголовка

Сначала определите изменение состояния маршрута. POST, меняющий аккаунт, требует сессии, авторизации и CSRF-защиты. Fetch Metadata добавляет проверку контекста: неожиданное cross-site изменение можно отклонить или оспорить, а публичный ресурс без состояния разрешить. При отсутствии поля используйте token и обычную авторизацию, а не безусловное разрешение. OAuth- и платёжные исключения должны иметь allowlist и подписанный state.

Построение CSRF-политики

До middleware составьте таблицу: same-origin mutation с валидными сессией и token продолжается; cross-site mutation отклоняется; публичное чтение разрешается; отсутствие поля идёт в совместимую ветку. Проверяйте метод, маршрут, сессию, token, Origin или Referer и Fetch Metadata вместе. Храните короткую причину. Не считайте все поддомены same-site доверенными, если владельцы различаются. Для опасных маршрутов допустима более строгая проверка без поломки документированных клиентов.

Клиенты без заголовков и необычные случаи

Мобильные приложения, CLI, WebView и шлюзы могут не иметь или менять поля. В их контракте используйте token, подпись или mTLS, а не имитацию браузера. Наблюдайте edge и origin отдельно. Redirect, prefetch, повтор, служебные воркеры и расширения создают редкие сочетания: отмечайте их как наблюдённые или неизвестные и давайте безопасную альтернативу.

Границы приватности и наблюдаемости

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

Копируемая политика

function contextDecision(req) {
  const changing = ['POST', 'PUT', 'PATCH', 'DELETE'].includes(req.method);
  const site = req.headers['sec-fetch-site'];
  const mode = req.headers['sec-fetch-mode'];
  const dest = req.headers['sec-fetch-dest'];
  if (!changing) return { action: 'continue', reason: 'read-only' };
  if (!req.user || !validCsrfToken(req)) return { action: 'reject', reason: 'authentication-or-csrf' };
  if (site === 'cross-site') return { action: 'reject', reason: 'unexpected-cross-site' };
  if (site === undefined) return { action: 'challenge', reason: 'missing-context' };
  if (mode === 'no-cors' || dest === 'image' || dest === 'script')
    return { action: 'reject', reason: 'subresource-shape' };
  return { action: 'continue', reason: 'declared-context' };
}

Ожидаемый результат: продолжать только при валидной сессии и token, отклонять cross-site и форму подресурса, оспаривать отсутствие. Сервер всё равно проверяет тело, полномочия, повтор и бизнес-правила.

Тестирование с BotBrowser

Создайте синтетический endpoint с обезличенным решением. Зафиксируйте браузер, профиль, источники, метод, назначение и ожидаемый статус. Запустите same-origin, same-site, cross-site mutation, публичную cross-site-картинку, верхнюю навигацию и клиента без полей, а также неверный token. Записывайте вход, наличие и значения, решение, статус и ограничения. Не используйте реальные аккаунты, секреты, private URL или большой инвентарь устройства. После обновления повторяйте ту же fixture.

Итог

Fetch Metadata: ограниченный контекст. Соединяйте его с аутентификацией, авторизацией, CSRF, Origin, семантикой маршрута и контрактом callback. Определите поведение при отсутствии до enforcement, минимизируйте причины в журнале и добейтесь утверждения исключений владельцем сервиса. Не утверждайте, что Sec-Fetch-* доказывает человека, доверенный браузер, согласие или приватность.

FAQ

Может ли Sec-Fetch-Site заменить CSRF token?

Нет. Он может отсутствовать и не является проверяемым секретом; нужна отдельная CSRF-защита.

Означает ли same-origin, что запрос аутентифицирован?

Нет. Отдельно проверяйте сессию, полномочия, token и бизнес-правила.

Нужно ли отклонять любой запрос без Fetch Metadata?

Нет. Легитимные клиенты могут не отправлять поля; применяйте правило по маршруту.

Являются ли эти поля fingerprint?

Нет стабильной идентичности: значения меняются с браузером, навигацией и посредниками.

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

Повторяемое наблюдение объявленного синтетического маршрута, а не хранение третьей стороной и поведение всех браузеров.

Источники

• W3C Fetch Metadata
• MDN Fetch metadata request header
• MDN Sec-Fetch-Site
• Пользовательские HTTP-заголовки BotBrowser
• Приватность сетевой идентичности WebRTC
• Ответственное тестирование функций браузера