Graph API Explorer usa token de verdade: como testar sem expor a sua Página

A analista da agência abriu o Graph API Explorer para ver o formato da resposta de /{page-id}/posts. Para não perder tempo, gerou o token pela Página do cliente, marcando todas as permissões que apareceram. Fez a leitura, colou a resposta no ticket, com o token no meio, e deixou a aba aberta antes de ir almoçar. Aquele token não era de leitura: com ele, qualquer pessoa publicava e apagava posts na Página de uma marca com 200 mil seguidores.

A resposta curta: o explorador não é um ambiente de testes isolado. Ele é um cliente HTTP comum, que executa chamadas reais com o poder do token que você gerou. Teste com token de usuário de curta duração, com as permissões mínimas, de preferência numa Página e num app de teste. Confira o que um token pode no depurador de tokens antes de usar, nunca cole a chamada com o token em ticket ou chat e revogue as permissões quando um token aparecer onde não devia.

Por que o explorador é perigoso justamente por ser fácil

O explorador deixa você escolher o app, o tipo de token (de usuário ou de Página) e as permissões numa lista de caixas de seleção. Ao gerar o token, a Meta pede a sua autorização como se fosse um app qualquer. A partir daí, cada chamada é uma requisição real à Graph API: GET lê, POST cria ou altera, DELETE apaga. Não há modo de simulação.

A facilidade convida ao exagero. Marcar todas as permissões evita mensagens de erro durante o teste, e o token resultante pode fazer tudo o que você pode fazer na Página. Somado a isso, existe a diferença de duração entre tokens. Tokens de usuário gerados na hora são de curta duração. Já tokens de longa duração e tokens de Página obtidos a partir deles duram muito mais, e alguns podem nem ter data de expiração. Um token desses num ticket é uma credencial de produção publicada.

O que exatamente vaza

• O próprio campo de token do explorador, visível para quem passar pela tela ou receber um print.
• O trecho de código que o explorador oferece gerar para a chamada, que inclui o token.
• A URL completa copiada do navegador ou da aba de rede, quando o token vai como parâmetro.
• A resposta colada no ticket, quando ela contém tokens de Página no campo access_token, como acontece ao listar as Páginas que a pessoa administra.

Como testar com segurança, passo a passo

O exemplo é a Agência Farol, que integra a agenda de publicações com as Páginas dos clientes.

1. Use um app em modo de desenvolvimento e uma Página de teste criada pela agência, sem seguidores e sem vínculo com cliente.
2. Marque só as permissões da chamada que você vai testar. Para ler posts, não marque permissões de gerenciar ou publicar.
3. Gere um token de usuário na hora, que expira cedo. Não cole no explorador o token de longa duração que o sistema usa em produção.
4. Antes de usar um token cuja origem você não conhece, confira no depurador de tokens a que app ele pertence, que permissões tem e quando expira.
5. Para documentar uma chamada, copie a resposta e apague qualquer campo access_token antes de colar no ticket.
6. Ao terminar, limpe o campo de token e feche a aba. Se o token apareceu em print, chat ou ticket, revogue.

Conferir o que um token pode, pela linha de comando

O depurador de tokens da Meta mostra isso numa tela. Para scripts, o endpoint debug_token faz o mesmo. O token do app (APP_ID|APP_SECRET) vem de uma variável de ambiente carregada do cofre de segredos, e o token suspeito é digitado sem eco, para não ficar no histórico do shell:

read -rs TOKEN_SUSPEITO
curl -sG https://graph.facebook.com/debug_token --data-urlencode "input_token=$TOKEN_SUSPEITO" --data-urlencode "access_token=$FB_APP_TOKEN" | jq '.data | {app_id, type, is_valid, expires_at, scopes}'

Na Farol, o token que estava no ticket devolveu isto:

{
  "app_id": "1234567890123456",
  "type": "PAGE",
  "is_valid": true,
  "expires_at": 0,
  "scopes": [
    "pages_show_list",
    "pages_read_engagement",
    "pages_manage_posts"
  ]
}

Tipo PAGE, válido e com pages_manage_posts: quem tivesse o ticket publicava na Página do cliente. O expires_at zero indica que esse token não tinha data de expiração. Leitura de posts precisaria só das duas primeiras permissões.

Revogar quando vazou

A forma mais direta de matar o acesso é revogar as permissões que o usuário deu ao app. Isso invalida os tokens emitidos para aquele usuário naquele app, inclusive os de Página derivados deles:

curl -s -X DELETE -G https://graph.facebook.com/me/permissions --data-urlencode "access_token=$TOKEN_SUSPEITO"

Uma resposta com "success": true confirma. A mesma revogação pode ser feita pela pessoa nas configurações da conta do Facebook, removendo o app. Atenção ao efeito colateral: se o token vazado era do mesmo usuário e do mesmo app da integração de produção, a integração também perde acesso e alguém precisa autorizar de novo. É exatamente por isso que o teste não deve usar o app e o usuário de produção. A lógica de trocar primeiro e limpar depois está em segredo no Git se troca antes de limpar.

Onde fica o token de produção

O token que o sistema usa para publicar não passa pelo explorador nem pela mão de ninguém depois de configurado. Ele fica no cofre de segredos do servidor, é lido pela aplicação em tempo de execução e nunca aparece em log. Se alguém precisa investigar uma chamada que falhou em produção, usa o log da aplicação, sem o token, e reproduz no explorador com o token de teste. Os posts log útil não carrega token e token de bot não vai no Git cobrem o resto da higiene.

Erros comuns

• Marcar todas as permissões para evitar erro. O token de um teste de leitura ganha poder de publicar e apagar.
• Testar com a Página de um cliente. Um POST no lugar de um GET publica para milhares de seguidores.
• Colar no explorador o token de longa duração da produção. Uma credencial que não expira passa a ficar visível na tela.
• Colar resposta ou código gerado com token no ticket. O ticket vira um vazamento que fica pesquisável por anos.
• Deixar a aba aberta com o token. Qualquer pessoa que sentar no computador age em nome da Página.
• Achar que o token sumiu porque a aba fechou. Fechar a aba não revoga nada; o token continua válido até expirar ou ser revogado.

Checklist

• Os testes usam app em desenvolvimento e Página de teste.
• Cada token de teste tem só as permissões da chamada testada.
• O token de produção está no cofre do servidor e nunca foi colado no explorador.
• Você sabe conferir app, tipo, permissões e expiração de um token.
• Respostas coladas em ticket passam por remoção de access_token.
• Existe um procedimento escrito de revogação para token vazado.
• Ninguém da equipe deixa o explorador aberto com token ao sair da mesa.

Abra agora o explorador no seu computador: se alguém clicasse em enviar com um POST, o token que está ali publicaria em alguma Página real?