Кратко

  • Backend for Frontend в RFC 10017 становится конфиденциальным OAuth-клиентом, хранит access и refresh tokens в контексте cookie-сессии и добавляет нужный token к исходящему запросу. В браузере нет существующего токена для извлечения и client credentials для самостоятельного обмена нового authorization code.
  • Вредоносный JavaScript в легитимном origin всё равно вызывает endpoint, доступный обычному frontend. Browser прикладывает cookie, а BFF переводит session в token-bearing request. Остаётся client hijacking — более узкий, чем кража токена, но ограниченный только фактически доступными действиями.
  • Воспроизводимая квитанция связывает origin/build, session/cookie policy, CSRF result, endpoint, разрешённые host/path/method, audience/scopes, решение resource server, обработку response, anomaly decision и remediation.

В отчёте об атаке может не оказаться ни одного украденного credential и при этом остаться успешно выполненная нежелательная операция.

Скрипт не прочитал HttpOnly cookie, не нашёл access token в storage и не вынес refresh token. Он работал внутри origin приложения и сформировал обычный запрос. Browser добавил session, BFF нашёл соответствующий token, а resource server обработал действие.

RFC 10017 отделяет эту ситуацию от token theft. Документ OAuth 2.0 for Browser-Based Applications опубликован в августе 2026 года как Best Current Practice IETF авторами Aaron Parecki, Philippe De Ryck и David Waite. Профиль IETF, сохранённый 31 августа 2026 года, называет Parecki сопредседателем группы SCIM и перечисляет два RFC, включая RFC 10017. Его личный сайт описывает работу в области стандартов идентификации, сопровождение oauth.net и участие в OAuth Working Group.

Это точная атрибуция коллективной работы, а не единоличное авторство и не гарантия конкретного deployment. Реальный предел задают код и политики каждого оператора.

Модель угроз начинается внутри origin

Спор о месте хранения токена обычно предполагает, что исполняемый код доверен. RFC рассматривает состояние после прорыва: XSS, компрометация внешнего ресурса или иной дефект позволяет выполнять JavaScript либо WebAssembly в контексте приложения.

Такой код получает привилегии легитимного frontend. Он читает доступный storage, вызывает функции, меняет control flow, работает с same-origin contexts и отправляет backend requests. Контекстное кодирование, ограничение третьих ресурсов, Subresource Integrity, Content Security Policy и origin isolation остаются первичной защитой. Только прекращение исполнения предотвращает client hijacking как класс.

После запуска возможны четыре OAuth-сценария: разовая кража токена, постоянный перехват обновлений, получение нового набора через authorization flow и proxying requests через browser. Последний не требует извлечения. Browser или внешний компонент автоматически добавляет credential. Неэкспортируемое полномочие всё ещё может быть вызываемым.

BFF устраняет переносимое полномочие

RFC располагает три основных pattern по убыванию security. BFF — самый защищённый и настоятельно рекомендуется для business, sensitive и personal-data applications. Server становится confidential client, выполняет Authorization Code с PKCE, хранит tokens и проксирует каждый вызов ресурсов.

Authorization server выдаёт токены BFF. В отдельном отношении BFF создаёт browser session. Frontend отправляет cookie; BFF разрешает session state, убирает cookie из outbound request, добавляет access token и обращается к resource server.

Это действительно блокирует три сильных пути. JavaScript не копирует текущий token и не ловит каждую ротацию. Новый authorization code нельзя обменять без confidential-client credentials; PKCE отдельно защищает транзакцию. HttpOnly не даёт напрямую прочитать session state и превратить захват клиента в переносимую сессию.

Остаётся власть активного browser. Код внутри origin вызывает доступные endpoints. BFF не отличает доброе намерение от злого, если программы обладают одинаковыми execution privileges. Его функция — не выдавать независимый bearer token и сузить поверхность, которая остаётся вызываемой.

У переводчика должен быть конечный список выходов

BFF переводит inbound request с session в outbound request с token. Если input свободно определяет destination, компонент способен отправить токен серверу атакующего.

Поэтому RFC требует проверять destination hosts, поддерживать явный allowlist resource servers и строго валидировать dynamic host/path. Ограничение HTTP methods на endpoint уменьшает поверхность: route для чтения не должна выполнять DELETE, просто повторив входной метод.

Host недостаточен. Один domain может содержать user и admin APIs. URL может быть спрятан в body, а redirect — покинуть проверенный host. Воспроизводимая политика содержит scheme, host, path template, method, request schema, redirect rule, token audience, scopes и response class.

Resource server остаётся отдельным владельцем решения. Он валидирует issuer, audience, expiry и permissions, а затем авторизует object и operation. Широкий token плюс общий proxy расширяют hijacking. Узкие routes и object-level authorization оставляют фактическую границу.

Minimum Initial Specification здесь означает общий минимум — confidential client, защищённый cookie, CSRF defense, bounded proxy. Локальный оператор добавляет карту endpoints и прав. Фраза «совместимый BFF» не заменяет эту карту.

Cookie защищает сессию, но не доказывает намерение

RFC требует Secure и HttpOnly, рекомендует SameSite=Strict, path /, отсутствие Domain и prefix наподобие __Host-Http-. Client-side session с token material следует шифровать, чтобы не сохранять его на диске открытым текстом.

Настройки решают разные задачи: чтение script, небезопасный transport, subdomain sharing, filesystem exposure. Ни одна не сообщает, хотел ли пользователь выполнить конкретную операцию.

Cookie authentication требует CSRF protection. SameSite=Strict не всегда достаточно: разные subdomains одного registrable site могут быть same-site и cross-origin. Захват соседнего subdomain создаёт forgery path.

CORS полезен, когда гарантирован preflight. Safelisted request может быть отправлен, хотя чтение response потом заблокировано. RFC рекомендует custom header и требует проверять его во всех requests, если метод выбран. Framework anti-forgery/double-submit предоставляет альтернативу.

CSRF отделяет внешний origin от легитимного. Вредоносный same-origin code уже находится внутри разрешённой стороны. Успешный CSRF check нельзя считать подтверждением человеческого намерения.

Остаточное полномочие измеряется исполнением

Client hijacking слабее прямой кражи token. Атакующий зависит от browser, active session, BFF routes, CORS и resource authorization. Отсутствующий endpoint или object-level deny способны остановить действие. RFC сохраняет это существенное различие.

Но оно требует доказательства. Versioned inventory связывает endpoint с host, path, method, token, audience, scopes, object rule и response data. Затем контролируемый hostile same-origin code пробует выйти за каждую комбинацию. Проверка happy path не является проверкой границы.

BFF видит весь mediated traffic и подходит для rate limiting и anomaly detection. Нечеловеческий burst, редкая последовательность endpoints, необычный набор objects или session после invalid refresh token должны запускать investigation.

Та же видимость концентрирует privacy risk. Сторонний BFF может видеть все requests и responses. Data minimization, retention, tenant isolation и operator access становятся частью контракта. Перенос токена на server не означает разрешение на безграничное наблюдение.

Session lifetime должна следовать underlying authority. RFC советует связать её максимум с lifetime refresh token и прекращать session, когда token недействителен. Server-side sessions дают прямую revocation, но требуют state replication; client-side sessions проще масштабировать, но их контроль сильнее зависит от token expiry/revocation.

Сохранить квитанцию, не сохраняя секрет

Нельзя логировать raw tokens, client secret или полный cookie. Нужны непереиспользуемый session correlation ID, время создания/окончания, cookie policy, authentication event, code transaction, BFF client identity и frontend build.

К ним добавляются inbound endpoint, нормализованные method/path template, CSRF/origin/CORS result и schema validation. Для перевода сохраняются resource server, outbound path/method, allowlist version, несекретный token fingerprint, issuer, audience, scopes, expiry и релевантные refresh/rotation/revocation events.

Цепь завершают resource authorization, status, response transformation, rate-limit/anomaly decision, change owner и remediation. Тогда token exfiltration, session theft, CSRF, same-origin abuse, proxy escape и чрезмерная downstream authorization остаются разными случаями с разными владельцами.

Running-Code Primacy задаёт окончательный тест: выполнить контролируемый hostile script внутри origin и доказать, что он не читает token/session, не завершает независимый flow, не выходит за host/path/method и object rights, а необычное использование разрешённой операции оставляет понятный alert и receipt.

BFF успешен, когда token не выходит, а оставшееся request authority узко, наблюдаемо и отзывно.

Источники