Como tratamos seus tokens

O UltronChat nunca armazena seus tokens OAuth em texto puro. Toda credencial sensivel (Instagram, Messenger, WhatsApp) passa por uma camada de criptografia simetrica e fica isolada por usuario via Row-Level Security do Postgres.

Criptografia de tokens OAuth

Quando voce conecta uma conta:

1. O dashboard faz o fluxo OAuth padrao da Meta e recebe um access_token de longa duracao.
2. Imediatamente, o token e criptografado com AES-256-GCM usando HKDF para derivar a chave a partir de uma master key armazenada em variavel de ambiente (TOKEN_ENCRYPTION_KEY).
3. O texto cifrado e gravado na coluna encrypted_access_token da tabela connections. O token original nunca toca disco nao-cifrado.

Quando uma Edge Function precisa enviar uma mensagem, ela:

1. Le encrypted_access_token do banco.
2. Decripta em memoria.
3. Faz a chamada a Graph API da Meta.
4. Descarta o token apos a requisicao — nunca persiste a forma decifrada.

O que isso significa na pratica

• Um dump do banco nao expoe tokens. O atacante precisaria tambem da master key.
• A master key fica em secrets gerenciados (Vercel para dashboard, Supabase Edge Function Secrets para backend), jamais no repositorio.
• Mesmo administradores do UltronChat nao conseguem "ler" seu token — apenas o processo automatizado decripta em tempo de execucao.

Row-Level Security (RLS)

Todas as tabelas com dados de usuario tem policies RLS que filtram automaticamente por auth.uid():

• connections — so SELECT onde user_id = auth.uid().
• agents, automations, conversations, messages, leads — JOIN com connections para garantir ownership.
• subscriptions, user_api_keys — filtradas por user_id.

Isso significa que mesmo se um bug expuser o endpoint do banco (ex.: anon key vazada), um usuario nao consegue ler dados de outro. A isolacao e enforced no nivel do Postgres.

Validacao HMAC de webhooks

Webhooks da Meta sao recebidos pelo Cloudflare Worker (webhook-gateway). Antes de enfileirar qualquer evento no sistema interno, o Worker valida o cabecalho X-Hub-Signature-256:

1. Calcula HMAC SHA256 do body com o App Secret correspondente.
2. Compara (timing-safe) com a assinatura recebida.
3. Se nao bater, retorna 401 e o evento nao entra na fila.

O UltronChat usa tres App Secrets diferentes — um para Instagram, um para Messenger (app principal), e um para WhatsApp (app dedicado B). Isso garante que mesmo se um secret for comprometido, as outras plataformas continuam seguras.

TLS em toda comunicacao

• Dashboard (Vercel) — HTTPS com HSTS habilitado e max-age=63072000 (2 anos).
• Supabase API e Edge Functions — HTTPS nativo.
• Cloudflare Worker — HTTPS nativo.
• Upstash QStash / Redis — HTTPS nativo.

Nenhuma parte do sistema aceita HTTP puro.

Headers de seguranca

O dashboard envia em toda resposta:

• X-Frame-Options: DENY — previne clickjacking.
• X-Content-Type-Options: nosniff — previne MIME sniffing.
• Referrer-Policy: strict-origin-when-cross-origin.
• Strict-Transport-Security (HSTS) — forca HTTPS.
• Content-Security-Policy restritiva — so permite scripts do proprio dominio.

Auditoria

Operacoes sensiveis sao logadas:

• Eventos de assinatura (subscription_events).
• Execucoes de automacao (automation_logs).
• Validacoes de BYOK (user_api_keys.last_validated_at, last_error).

Logs brutos de Edge Functions e Worker sao rotacionados e acessaveis apenas pelo time operacional.

Proximos passos

• BYOK e chaves de API — como protegemos suas chaves do OpenAI / Anthropic.
• LGPD e privacidade — resumo do que coletamos e seus direitos.