O preço founding está aberto: Pro ao preço de hoje, travado enquanto você ficar. Vagas limitadas. Ver a oferta
Segurança
Esta página descreve as medidas a que o contrato de subcontratação remete. Está escrita para ser verificável: cada medida nomeia o que a aplica, para que uma revisão de segurança possa confirmar em vez de acreditar.
Cifragem
Todo o tráfego é servido sobre TLS. Os tokens OAuth de terceiros (Shopify, Google, Meta, Klaviyo, Notion, Figma) são cifrados em repouso com AES-256-GCM sob uma chave que suporta rotação, pelo que um despejo da base de dados não devolve credenciais utilizáveis. Os relatórios de verificação de identidade são cifrados com o mesmo esquema e nunca são mostrados no produto.
Isolamento de inquilinos
Todas as consultas que alcançam dados de organização ou de loja são delimitadas pela pertença, e essa delimitação está coberta por testes que fazem a compilação falhar em vez de depender de disciplina de revisão. As funções são owner, admin, member e viewer, e as permissões são verificadas no servidor em cada pedido, nunca no cliente.
Autenticação
O início de sessão usa um código de utilização única de seis dígitos enviado por e-mail. Não há palavra-passe para vazar nem ligação mágica para reencaminhar. As sessões viajam num cookie com o prefixo __Secure-, expiram ao fim de 30 dias e descem para 24 horas quando inicia sessão sem pedir para ser recordado.
Registo de auditoria
Os eventos de segurança e faturação são escritos num registo apenas de adição, visível na atividade da sua conta. As ações administrativas da plataforma são registadas à parte. As cargas úteis brutas dos webhooks são eliminadas com um calendário mais curto do que os próprios eventos: o registo sobrevive, as cargas úteis não.
Segredos
Nenhuma credencial está no repositório. O painel de operador que reporta a configuração de ambiente expõe apenas se uma chave está definida, nunca o seu valor. Um teste rejeita qualquer valor que se pareça com um segredo no ficheiro de configuração MCP versionado.
Integridade e controlo de alterações
As alterações ao esquema da base de dados são derivadas automaticamente e aplicadas de forma idempotente, com uma guarda que recusa qualquer alteração capaz de falhar em produção assim que uma tabela tem linhas. Um hook de pre-push executa guardas offline rápidas (esquema, claims de documentação, copy, versões) antes de uma alteração chegar ao remoto. Lint, typecheck e a suíte de testes completa correm em CI em cada pull request. A documentação que está a ler está ela própria protegida: os números publicados são comparados com o código que os implementa.
Infraestrutura
A plataforma corre na Vercel com uma base de dados PostgreSQL gerida na Neon, que fornece cópias contínuas e restauro para um instante preciso. Cache e filas correm na Upstash. Os pagamentos nunca tocam nos nossos servidores: os dados do cartão são tratados pela Stripe. A região de cada fornecedor está publicada na página de subcontratantes.
Monitorização
A plataforma publica uma página de estado em direto com 90 dias de histórico e um boletim mensal de disponibilidade. Os incidentes são aí declarados, com feed RSS e subscrição por e-mail. As falhas ao nível da plataforma (registos, pagamentos falhados) são resumidas ao operador de hora a hora.
Comunicar uma vulnerabilidade
Escreva para contact@boostecom.app com detalhe suficiente para reproduzir. Acusamos a receção em três dias úteis. Não intentaremos ações legais contra investigação de boa-fé que respeite a privacidade dos utilizadores, evite destruição de dados e não degrade o serviço. Por favor, não faça testes na conta ou na loja de outro utilizador.
Última atualização 12 de setembro de 2026