Segurança
Este documento descreve como o AppKit é construído hoje. Sem alegações que não podemos provar: não temos certificações SOC 2 ou ISO 27001 e não afirmamos tê-las.
Arquitetura de acesso ao banco
- A API serverless nunca usa credencial administrativa (service role) e nunca escreve diretamente em tabela.
- Toda escrita passa por funções
SECURITY DEFINERno Postgres, com Row Level Security (RLS) ativo. Acesso anônimo às funções de painel retorna permission denied. - Isolamento por workspace (tenant): a chave pública dá acesso apenas à configuração publicada e à ingestão de eventos daquele workspace.
Pseudonimização por construção
O identificador do usuário final nunca é gravado cru: vira hash SHA-256 com salt exclusivo por workspace antes de tocar o banco. Não é possível reverter o hash para descobrir quem é o usuário.
O SDK no seu produto
- Roda isolado em Shadow DOM — não lê nem altera o seu CSS e não coleta conteúdo da página.
- Falha aberta: qualquer erro faz o widget não aparecer; nenhum erro escapa para o seu código.
- Sem cookies de rastreamento e sem coleta de texto digitado.
Publicação, versionamento e reversão
- Cada publicação cria um snapshot imutável e versionado da configuração.
- Rollback é apontar para a versão anterior.
- Kill switch: um botão desliga o AppKit em todos os seus usuários em até 30 segundos.
- A URL do SDK é imutável por versão — o arquivo servido nunca muda depois de publicado.
Transporte e chaves
- Todo o tráfego é servido por HTTPS.
- A chave
pk_é pública por design: só lê configuração publicada e envia eventos. Nenhum segredo vive no navegador.
Infraestrutura
Hospedagem na Vercel (região São Paulo para o tráfego brasileiro); banco e autenticação no Supabase (Postgres gerenciado).
Encontrou uma vulnerabilidade?
Escreva para contato@appkit.com.br. Respondemos e corrigimos com prioridade.