Resumo

  • Na RFC 10017, o BFF é o cliente OAuth confidencial. Ele administra access e refresh tokens no contexto de uma sessão por cookie e acrescenta o token apropriado às chamadas de recursos. Não há token no navegador para extrair nem credencial de cliente para trocar, de forma independente, um novo authorization code.
  • JavaScript malicioso na origem legítima ainda consegue enviar uma requisição que o frontend normal saberia formular. O navegador inclui a sessão e o BFF faz a tradução. O risco remanescente é client hijacking: menor que o domínio direto de um token, porém tão amplo quanto as ações expostas.
  • O comprovante útil une origem e build, sessão e política do cookie, resultado de CSRF, endpoint, host/caminho/método permitidos, audience e scopes, autorização do servidor de recursos, transformação da resposta, anomalia e remediação.

Um bom teste de segurança pode terminar com uma frase que parece paradoxal: o token não vazou, mas a conta realizou uma ação indevida.

O script malicioso não leu o cookie HttpOnly, não encontrou access token no armazenamento e não levou refresh token para outro computador. Executou-se na origem da aplicação, chamou uma rota legítima e deixou o navegador anexar a sessão. O BFF encontrou o token correspondente e encaminhou a operação.

A RFC 10017 separa esse percurso do roubo de credenciais. Publicada em agosto de 2026 como Best Current Practice do IETF, OAuth 2.0 for Browser-Based Applications tem autoria coletiva de Aaron Parecki, Philippe De Ryck e David Waite. O Datatracker preservado em 31 de agosto de 2026 registra Parecki como copresidente do grupo SCIM e lista duas RFCs, entre elas a 10017. O site do próprio Parecki descreve sua função em padrões de identidade, a manutenção do oauth.net e a participação no OAuth do IETF.

Esses registros explicam sua relevância, não dão autoria exclusiva nem certificam deployments. A autoridade concreta nasce do mapa que cada BFF realmente executa.

O cenário começa depois da entrada do código hostil

Perguntar onde o token fica guardado é necessário, mas insuficiente. A análise da RFC parte de JavaScript ou WebAssembly malicioso rodando no mesmo execution context do aplicativo. Ali, o código adversário possui os privilégios do código legítimo: acessa storage disponível, chama funções, altera o fluxo e envia requisições à origem esperada.

Codificação contextual, redução de terceiros, Subresource Integrity, Content Security Policy e isolamento de origens continuam essenciais. Impedir a execução é a única maneira de impedir completamente o sequestro do cliente. A arquitetura define o estrago possível quando essa barreira falha.

Há quatro caminhos OAuth: roubar os tokens uma vez; capturar continuamente os tokens renovados; iniciar um fluxo novo e extrair credenciais próprias; ou não roubar nada e enviar solicitações pelo navegador. No último caso, browser ou componente externo acrescenta automaticamente o elemento de autorização.

Uma credencial não exportável impede transporte. Não impede que uma operação seja invocada dentro da sessão que já a alcança.

O BFF remove autoridade portátil

Entre os três padrões principais, o BFF oferece a proteção mais forte e é recomendado com ênfase para aplicações empresariais, sensíveis e com dados pessoais. O servidor torna-se cliente confidencial, executa Authorization Code com PKCE, conserva os tokens e faz proxy de todas as interações com recursos.

O authorization server entrega tokens ao BFF. Em outra relação, o BFF cria uma sessão com o navegador. Quando o frontend solicita um recurso, envia cookie ao BFF; ele resolve o estado, remove o cookie da chamada de saída, anexa o access token e conversa com o resource server.

Isso elimina três capacidades importantes. JavaScript não lê o token existente nem captura as rotações. Mesmo que obtenha um authorization code, não consegue trocá-lo sem as credenciais do cliente confidencial; PKCE protege outra parte da transação. HttpOnly impede acesso direto à sessão, evitando que client hijacking se converta automaticamente numa sessão que o atacante carrega para fora.

O poder restante depende do navegador ativo. O código da origem ainda chama endpoints que o aplicativo chama. O BFF não distingue a intenção de dois programas com os mesmos privilégios; ele impede que um deles adquira uma credencial autônoma e oferece um lugar para limitar o conjunto de ações.

Todo destino do tradutor precisa ser explícito

O BFF traduz uma requisição com sessão para outra com token. Se o destino vier livremente da entrada, o componente pode enviar o token a um servidor adversário.

Por isso, a RFC exige validação de hosts, allowlist explícita de resource servers e controle rigoroso de rotas dinâmicas. Limitar HTTP methods por endpoint reduz o alcance. Uma rota de leitura não deve virar rota de exclusão porque o proxy apenas repetiu o verbo recebido.

Host não basta. Um domínio pode reunir API de usuário e administração. Parâmetros podem carregar URLs e redirects podem atravessar a fronteira depois da primeira checagem. A política auditável contém scheme, host, path template, method, schema da requisição, regra de redirect, token audience, scopes e classe de resposta.

O resource server mantém decisão própria. Valida issuer, audience, expiração e permissões, depois autoriza o objeto e a operação. Token amplo com proxy genérico aumenta o sequestro; rotas estreitas e autorização por objeto preservam limites.

É a aplicação prática da Minimum Initial Specification: a RFC define cliente confidencial, cookie protegido, CSRF e proxy limitado; cada operador define o mapa local sem fingir que a expressão “BFF compatível” descreve suas ações.

Cookie seguro não é recibo de intenção

Secure e HttpOnly são obrigatórios. SameSite=Strict, path /, ausência de Domain e um prefixo como __Host-Http- são recomendados. Se uma client-side session carregar material de token, a RFC recomenda cifrar o conteúdo para evitar persistência em claro.

Essas medidas respondem se script pode ler, transporte inseguro pode receber, subdomínio pode compartilhar ou malware de disco pode ver o token. Não respondem se o usuário desejou aquela ação.

Autenticação por cookie exige CSRF. SameSite=Strict pode falhar na presença de aplicações sob o mesmo site registrável: subdomínios diferentes são same-site e cross-origin. O takeover de um irmão abre uma rota de falsificação.

CORS ajuda se houver preflight obrigatório. Requisições safelisted podem ser enviadas mesmo que a resposta não fique acessível ao origin chamador. A RFC recomenda um custom header e, quando ele é escolhido, obriga o BFF a verificá-lo em toda requisição. Anti-forgery do framework é outra opção.

Nenhum controle CSRF diferencia código bom e ruim já instalado na origem legítima. Resultado CSRF positivo não pode ser promovido a consentimento humano.

Medir o conjunto de ações restante

Client hijacking é menos poderoso que token theft porque permanece preso ao navegador, à sessão, às rotas do cliente e à autorização downstream. CORS estrito, endpoint ausente e object-level deny podem conter a ação. A distinção é importante.

Mas precisa ser testada. Inventariar endpoint, host, path, method, token, audience, scopes, regra de objeto e dados de resposta. Depois executar código hostil controlado na origem e tentar combinações fora da lista. Revisar somente o happy path não prova a fronteira.

O BFF observa todo o tráfego mediado. Rate limiting e anomaly detection podem identificar rajadas incompatíveis com comportamento humano, sequência rara de rotas, conjunto anormal de objetos ou sessão que continua após invalidação do refresh token. A mesma observabilidade exige limites de privacidade, sobretudo se terceiro hospeda o componente: minimização, retenção, isolamento e acesso operacional.

A sessão deve seguir a vida da autorização subjacente. A RFC orienta alinhar sua duração máxima à do refresh token e invalidá-la quando ele deixa de funcionar. Server-side session facilita revogação e custa replicação; client-side session escala melhor e depende mais de revogação/expiração dos tokens.

Guardar o comprovante sem guardar o segredo

Não registrar tokens, client secret ou cookie completo. Guardar um identificador de correlação não reutilizável, criação e expiração da sessão, política do cookie, autenticação, transação de code, identidade do cliente BFF e versão do frontend.

Somar endpoint, método e path normalizados, resultado de CSRF/origin/CORS e validação do request. Na saída, registrar resource server, path, method, versão da allowlist, fingerprint não secreto do token, issuer, audience, scopes, expiry e evento de refresh/rotação/revogação relevante.

Completar com autorização do resource server, status, transformação de resposta, decisão de rate limit/anomalia, dono da mudança e caminho de reparo. Assim, exfiltração de token, roubo de sessão, CSRF, abuso same-origin, escape de proxy e autorização downstream excessiva não viram um único evento sem responsável.

Running-Code Primacy fornece o teste: código hostil controlado não lê token/session, não termina um fluxo independente, não escapa do host/path/method, não vence autorização de objeto e deixa alerta inteligível ao abusar de ação tecnicamente permitida.

O BFF está funcionando quando o token não sai e a autoridade que resta é estreita, observável e revogável.

Fontes