Кратко

  • RFC 10017 опубликован в августе 2026 года как Best Current Practice IETF. Для деловых и чувствительных приложений, а также систем с персональными данными он настоятельно рекомендует Backend for Frontend, который не передаёт OAuth-токены браузерному коду.
  • BFF снижает риск разовой и постоянной кражи токенов и получения новых токенов. Но вредоносный код в том же origin может отправлять запросы с cookie действующей сессии. Доказательство сохранности секрета не доказывает намерение пользователя.

Инцидент, в котором ничего не пропало

Начальная сцена — аналитическая конструкция, а не описание известного публичного инцидента. Она разделяет два вопроса, которые расследование часто ошибочно объединяет. Где находились учётные данные? И какие действия смог выполнить аутентифицированный контекст? На первый вопрос можно дать безупречно спокойный ответ и при этом обнаружить ущерб во втором.

RFC 10017 начинает с границы полномочий браузера. Если вредоносный JavaScript уже выполняется в origin приложения, он не является изолированным субъектом с урезанными возможностями. Он видит данные страницы, использует хранилище origin, взаимодействует с другими контекстами того же origin и посылает запросы на сервер. Скомпрометированной зависимости незачем копировать строку секрета, если браузер и BFF готовы применить связанную с ним власть от её имени.

Документ выделяет четыре сценария, значимых для OAuth: однократную кражу имеющихся токенов, постоянное извлечение при их ротации, получение свежих токенов через новый поток авторизации и проксирование запросов через браузер жертвы. Последний сценарий объясняет, как нежелательная операция происходит в тот момент, когда все токены остаются на предусмотренных местах.

Для BFF запрос от законного компонента и запрос, вызванный вредоносным кодом, могут выглядеть одинаково. Оба исходят из ожидаемого origin, оба заставляют браузер приложить cookie и оба соблюдают формат API. Затем BFF выбирает токен доступа и добавляет его к исходящему вызову. Атакующий получает результат, не увидев ни cookie, ни токена.

Поэтому вывод «токен не украден» должен оставаться узким. Он подтверждает, что bearer-значение не покинуло хранилище и не стало переносимой возможностью для повторного использования с другого устройства. Он не подтверждает намерение пользователя, корректность карты маршрутов BFF или правомерность бизнес-действия на ресурсном сервере.

BFF меняет последствия, а не доверие к origin

Backend for Frontend выступает конфиденциальным OAuth-клиентом. Он хранит токены доступа и обновления на сервере, поддерживает сессию браузера через cookie и перенаправляет запросы к ресурсам после добавления подходящего токена. Браузеру доступен интерфейс сессии, но не сами учётные данные.

Это даёт существенную защиту. В браузере нет токена доступа для копирования; вредоносный код не наблюдает ротацию токена обновления и не может сам обменять новый код авторизации без конфиденциальных данных BFF. RFC считает первые три сценария эффективно смягчёнными и особенно рекомендует такую архитектуру там, где важны деловые операции, конфиденциальность и персональные данные.

Проксирование через браузер сохраняется. HttpOnly мешает JavaScript прочитать cookie, но не мешает браузеру автоматически включить её в допустимый запрос. Код из того же origin вызывает BFF, браузер предъявляет сессию, BFF находит токен и отправляет запрос дальше. Вся цепочка работает штатно, хотя исходный импульс был захвачен.

Преимущество BFF в том, что атакующий ограничен действиями, разрешёнными сессией, маршрутами прокси и политикой ресурса. Захват клиента не превращается автоматически в долговечные переносимые полномочия, пригодные вне устройства. Однако каждый фрагмент кода в origin не становится от этого доверенным субъектом.

Такой взгляд позволяет избежать крайностей. Неверно обесценивать BFF из-за сохранения client hijacking: последствия действительно уже. Неверно и считать наличие BFF полным доказательством авторизации. Следует точно называть тот вред, который механизм предотвращает, и решения, которые остаются за соседними уровнями.

Нечитаемая cookie остаётся действующей властью

BCP требует для cookie BFF атрибуты Secure и HttpOnly. Также рекомендуются SameSite=Strict, путь /, отсутствие Domain и подходящий префикс, ограниченный конкретным хостом. Эти меры сокращают сетевую экспозицию, чтение скриптами и чрезмерное распространение между поддоменами.

Ни одна из них не доказывает волю пользователя. Взаимодействия с BFF, основанные на cookie, требуют полноценной защиты CSRF. SameSite полезен, но соседние поддомены относятся к одному site, даже если имеют разные origin. Захват одного поддомена может открыть путь, который поверхностная проверка SameSite сочла закрытым.

CORS тоже следует подтверждать конкретно. Некоторые safelisted-запросы уходят без preflight; браузер может скрыть ответ, но не предотвратить эффект. Обязательный нестандартный заголовок способен принудительно вызвать preflight. Аудит должен доказать, что каждый чувствительный endpoint отклоняет запросы без него, а не просто отметить включённый CORS.

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

Надёжная запись связывает выдачу, продление, истечение, выход и отзыв. Пока BFF принимает защищённую cookie, это не пассивный секрет, а активный носитель полномочий сессии.

Карта прокси — часть авторизации

BFF не только сейф для токенов. Он переводит входящий запрос, аутентифицированный cookie, в исходящий вызов, авторизованный bearer-токеном. Выбор хоста, пути и метода определяет, какую власть может израсходовать сессия.

RFC 10017 требует строгого контроля исходящих направлений. Хосты должны входить в список разрешённых, динамические части пути — проверяться, методы — ограничиваться для каждой операции. Открытый или чрезмерно динамический прокси может направить действующий токен не тому хосту либо открыть действие, которое интерфейс никогда не собирался предоставлять.

Например, /bff/payments/{id} — не просто технический канал. Маршрут решает, может ли сессия только читать или также отменять, возвращать и изменять, а также какие идентификаторы допустимы. Ресурсный сервер по-прежнему обязан проверить audience, scope, субъект и правило конкретной операции. Верное перенаправление ещё не оправдывает итоговый эффект.

Наблюдаемый результат завершает доказательство. BFF может записать успешный ответ, хотя асинхронный процесс позднее отклонит операцию. Повторные попытки способны создать дубликаты. Общий исходящий IP для множества пользователей искажает ограничение частоты, рассчитанное на прямых клиентов. Идентификатор запроса, сессия, решение маршрута, выбранный токен, решение ресурса и конечное состояние должны соединяться в одной временной линии.

Перемещается и граница приватности. BFF наблюдает все передаваемые запросы и ответы. Сторонний оператор уменьшает присутствие токенов в браузере, но получает широкий обзор поведения и содержания. Безопасность учётных данных и минимизация данных — разные решения, каждое со своей ответственностью.

Три архитектуры оставляют разные следы

BCP сравнивает полный BFF, посреднический backend и OAuth-клиент только в браузере. В первом случае оба вида токенов остаются на сервере, а все вызовы ресурсов проходят через прокси. Во втором конфиденциальные данные клиента и токен обновления защищены сервером, но токен доступа возвращается браузеру. В третьем поток OAuth и токены полностью принадлежат браузерному runtime.

Посредник сокращает риск кражи возможности обновления и нового обмена кода, однако токен доступа снова доступен скомпрометированной среде. Его извлечение и непосредственное использование остаются возможными. Это не «почти BFF», а другое распределение последствий и доступной доказательной базы.

Клиент только в браузере подвержен всем четырём сценариям. Для него обязателен Authorization Code с PKCE. Токены обновления должны ротироваться либо быть привязанными к отправителю, а также иметь максимальный срок или срок бездействия. Меры ограничивают перехват и долговечность, но не изолируют вредоносный код, который уже находится в законном origin.

DPoP создаёт ещё одну полезную, но ограниченную защиту. Токен, связанный с неэкспортируемым ключом, труднее использовать вне устройства. Это не мешает браузеру отправлять запросы по команде вредоносного кода. Если такой код способен начать новый поток, он может попытаться связать свежие токены со своим ключом. Утверждение о sender binding имеет смысл только вместе с данными о контексте, ключе и потоке выдачи.

Не всякому frontend и API под одним доменом нужен OAuth между собой. Если они составляют одно приложение без независимой ресурсной стороны, федеративная аутентификация с последующей собственной сессией может точнее выразить отношения. OAuth без реальной границы доверия добавляет токены и прокси, но не разделяет полномочия.

Утверждение не должно быть шире механизма

Ценность RFC 10017 в том, что он не обещает enclave внутри браузера. Документ сопоставляет угрозы и последствия конкретным средствам. BFF — сильный локальный ответ на экспозицию токенов. Он не объявляет весь код origin доверенным, не доказывает намерение каждой операции и не заменяет авторизацию ресурса.

Защищаемая операционная запись включает происхождение кода и зависимостей, origin, выдачу и истечение сессии, атрибуты cookie, время, метод, путь и класс тела запроса, результаты CSRF и CORS, маршрут BFF, audience и scope токена, решение ресурса, ответ, бизнес-эффект и владельца отката. У каждого элемента свой владелец и свои часы.

Так сохраняется тонкая координация. Общая BCP задаёт минимум и перечисляет варианты; локальная сторона решает, какие зависимости принимать, какие маршруты открывать, как наблюдать аномалии и что оставлять обратимым. Выполняющийся код и фактически замеченные запросы важнее архитектурной схемы с подписью BFF.

Организация, которая несёт потери от мошенничества, нарушения приватности и простоя, должна сохранять последнее слово: какую операцию допустить, увидеть, остановить и отменить. Хранение токенов на сервере — важная половина решения. Узкие полномочия сессии — вторая.

Источники